Group type-only imports and fix missing type keyword on PDA seeds imports - #176
Open
macalinao wants to merge 1 commit into
Open
Group type-only imports and fix missing type keyword on PDA seeds imports#176macalinao wants to merge 1 commit into
macalinao wants to merge 1 commit into
Conversation
…orts
When every identifier a generated file imports from a given module is type-only, the import is now rendered as a single `import type { ... }` statement instead of inlining a `type` marker on each specifier. Under `verbatimModuleSyntax` the inline form leaves behind an empty `import {} from '...'` side-effect statement in the emitted JavaScript, which the grouped form erases entirely. Modules that mix value and type imports keep the existing inline form.
Separately, account PDA helpers imported the PDA seeds type without a `type` keyword even though it is only ever referenced in type position, so generated clients tripped TS1484 under `verbatimModuleSyntax` whenever an account was linked to a PDA with variable seeds.
The checked-in e2e fixtures were regenerated; the only resulting change is one import statement in the dummy client.
🦋 Changeset detectedLatest commit: c9cdbe5 The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
This was referenced Aug 1, 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
1 participant
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.
Two small fixes that make generated clients cleaner under
verbatimModuleSyntax, which every e2e fixture tsconfig already enables.Group type-only imports
When every identifier a generated file imports from a given module is type-only, the import is now rendered as a single
import type { ... }statement rather than inlining atypemarker on each specifier. The two forms are equivalent to the type checker, but they differ in what TypeScript emits: underverbatimModuleSyntaxthe inline form erases the specifiers and leaves an emptyimport {} from '...'side-effect statement behind in the emitted JavaScript, while the grouped form is erased entirely. Modules that mix value and type imports keep the existing inline form, since only a fully type-only group can be hoisted toimport type.Fix the PDA seeds type import
getAccountPdaHelpersFragmentimported the PDA seeds type (e.g.BarSeeds) without atypekeyword, even though it is only ever referenced in type position on theseedsparameter. Any generated client with an account linked to a PDA that has variable seeds therefore failed to compile with TS1484 underverbatimModuleSyntax. The identifier is now imported astype BarSeeds;mergeImportMapsalready lets a value import win over a type import, so this stays correct if the same name is also needed as a value.Notes for consumers
Regenerating a client will produce cosmetic
import { type A }→import type { A }diffs. No runtime behavior changes.The checked-in e2e fixtures were regenerated as part of this change to keep CI's clean-working-tree invariant satisfied; the only resulting diff is a single import statement in the dummy client.
Related work
Part of #180 — running generated clients natively on Node.js 24+ TypeScript (type stripping), with no separate compilation step:
import typegrouping and the missingtypekeyword fix (verbatimModuleSyntaxpolish)importExtensionoption — explicit.js/.tsextensions on relative importserasableSyntaxoption — erasable replacements for generatedenumdeclarationsmoderne2e fixture generated with both options (draft, stacked on Add importExtension option for explicit extensions on relative imports #177 and Add erasableSyntax option to generate erasable enum alternatives #178)