fix(tsgen): stop modular block interfaces colliding with other generated names - #201
Open
naman-contentstack wants to merge 1 commit into
Open
fix(tsgen): stop modular block interfaces colliding with other generated names#201naman-contentstack wants to merge 1 commit into
naman-contentstack wants to merge 1 commit into
Conversation
…ted names
REST-mode type generation emitted two interfaces with the same name when a
modular blocks field's UID matched the UID of a content type, producing a
.d.ts that does not compile:
export interface Form { heading?: string } // content type `form`
export interface Form { heading: { ... } } // blocks field `form`
TypeScript then reports TS2687 and TS2717 on the merged members.
Block interface names were de-duplicated only against other block names, so
they were blind to content types, global fields and the builtin interfaces.
Content types are also generated one at a time, so the factory could not see
a content type it had not reached yet.
Route every block name through a single registry, seeded up front with the
builtin names and with every top-level name in the batch:
- interfaceNameForUid() is now the one place a UID becomes a name.
- collectBuiltinInterfaceNames() reads the builtin names from
stack/builtins.ts rather than restating them, so the list cannot drift, and
passes the real emission flags so names that are not emitted are not
reserved.
- generateTSFromContentTypes reserves all top-level names before the loop,
making the fix independent of content type ordering.
- The prefix is normalised once at that boundary so the builtins, the
reserved names and the generated interfaces agree.
Top-level interfaces are never renamed: customers import those by name. Only
the derived block interface is suffixed, and the suffix counter is
deliberately left shared so existing output is unchanged - a stack that
produces Card2 today still produces Card2, not Card1.
A rename is now reported through the logger, matching every other
name-mangling path in the file, so a customer does not meet it first as a
"Cannot find name" error in their own build.
Group fields are unaffected: they are emitted inline and claim no name, so
they cannot collide. The ticket describes the trigger as a group field; the
customer's generated output confirms it is a modular blocks field.
Known gap, unchanged by this commit and tracked separately: a content type
whose UID maps to a builtin name still emits a duplicate. Both sides are
top-level, so neither can be renamed without breaking imports. Verified
byte-identical to the previous behaviour.
Fixes DX-10385
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
✅ Snyk checks have passed. No issues have been found so far.
💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse. |
|
Coverage report for commit: 0acd33a Summary - Lines: 81.18% | Methods: 77.97% | Branches: 64.12%
🤖 comment via lucassabreu/comment-coverage-clover |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
🔒 Security Scan Results
⏱️ SLA Breach Summary
ℹ️ Vulnerabilities Without Available Fixes (Informational Only)The following vulnerabilities were detected but do not have fixes available (no upgrade or patch). These are excluded from failure thresholds:
✅ BUILD PASSED - All security checks passed |
shafeeqd959
approved these changes
Aug 31, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
REST-mode type generation emits two interfaces with the same name when a modular blocks field's UID matches the UID of a content type. The generated
.d.tsdoes not compile:TypeScript reports
TS2687(mismatched modifiers onheading) andTS2717({}vsstring | undefined).Root cause
Three places emit interface names and none of them knew about the others:
define_interface)type_modular_blocks)stack/builtins.ts)Only block-vs-block was handled — that is the DX-1272 / DX-1333 / DX-2775 fix. A block colliding with a content type or a builtin was not.
Compounding it, content types are generated one at a time, so the factory could not know about a content type it had not reached yet. The collision therefore depended on stack ordering.
Fix
Every block name is allocated from one registry, seeded before generation with the builtin names and every top-level name in the batch.
interfaceNameForUid()— the single place a UID becomes a name.collectBuiltinInterfaceNames()— reads the builtin names fromstack/builtins.tsinstead of restating them, so the list cannot drift, and passes the real emission flags so names that are not emitted are not reserved (reserving an unemitted name renames a block and consumes the shared suffix counter).generateTSFromContentTypes— reserves all top-level names before the loop, so the fix does not depend on ordering.nullprefix no longer emitsnullFile.Two deliberate constraints
Top-level interfaces are never renamed. Customers import content type and global field interfaces by name. Only the derived block interface is suffixed.
Verification
22 suites / 91 tests / 18 snapshotsgreen; no snapshot changed.form+ blocks fieldformFormkept, block →Form1, compilesGroupTest+GroupTest1file,link,taxonomy,build_tuple,tuple_prefixes,max_tupleHero,Hero1,Card,Card2— unchanged from before--prefix,nullprefix,--include-system-fieldsNotes for reviewers
A rename is now logged. Previously silent; a customer's first sign was
Cannot find name 'Form'in their own build. This matches every other name-mangling path in the file.