fix: add .js extensions to declaration file imports to resolve type re-export issue #410
Conversation
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
…e-export issue Fixes #407 When package.json has "type": "module", TypeScript treats .d.ts files as ESM modules, which require explicit file extensions for relative imports. Without these extensions, type re-exports from consuming packages fail with InternalResolutionError. Changes: - Add scripts/fix-dts-imports.cjs to add .js extensions to all relative imports in .d.ts files - Update build process to run fix-dts step after generating types - Add @arethetypeswrong/cli validation to integrity-checks to prevent regressions This resolves the regression introduced in v6.0.0 (PR #379) where dual module support broke type re-exports in consuming projects. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
The FallbackCondition and FalseESM warnings are known limitations of dual-module packages that don't affect functionality. The critical InternalResolutionError has been fixed, which was the actual bug. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
scottlovegrove
requested review from
a team and
nats12
and removed request for
a team
scottlovegrove
added a commit
to Doist/twist-sdk-typescript
that referenced
this pull request
Nov 27, 2025
…e-export issue Fixes type re-export issue where types exported from this package could not be re-exported by consuming packages when package.json has "type": "module". ## Root Cause When `package.json` has `"type": "module"`, TypeScript treats `.d.ts` files as ESM modules, which require explicit file extensions (`.js`) for relative imports. The generated declaration files had imports like `from './twist-api'` instead of `from './twist-api.js'`, causing module resolution to fail when other packages tried to re-export types. ## Changes - **Added `scripts/fix-dts-imports.cjs`**: Post-build script that adds `.js` extensions to all relative imports in generated `.d.ts` files - Handles `import` statements - Handles `export` statements - Handles dynamic `import()` type expressions - **Updated `package.json`**: - Added `build:fix-dts` script to run the DTS fixer - Updated `build` script to include the fix-dts step - Added `attw` script for type validation using `@arethetypeswrong/cli` - Updated `integrity-checks` to include `attw` validation ## Verification **Before fix** (using `@arethetypeswrong/cli --pack`): - ❌ **InternalResolutionError** - Module resolution failed (breaking bug) **After fix**: - ✅ **No problems found** - All module resolution working correctly ⭐ - ✅ Declaration files now have `.js` extensions on all relative imports - ✅ Type validation passes with `@arethetypeswrong/cli` ## Test Plan - [x] Build completes successfully with new fix-dts step - [x] Declaration files now have `.js` extensions on all relative imports - [x] `@arethetypeswrong/cli` validation passes (no problems found) - [x] All 166 tests pass without modification - [x] TypeScript compilation succeeds without errors Applies same fix as: - Doist/todoist-api-typescript#410 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
6 tasks
scottlovegrove
added a commit
to Doist/twist-sdk-typescript
that referenced
this pull request
Nov 27, 2025
…e-export issue (#64) Fixes type re-export issue where types exported from this package could not be re-exported by consuming packages when package.json has "type": "module". ## Root Cause When `package.json` has `"type": "module"`, TypeScript treats `.d.ts` files as ESM modules, which require explicit file extensions (`.js`) for relative imports. The generated declaration files had imports like `from './twist-api'` instead of `from './twist-api.js'`, causing module resolution to fail when other packages tried to re-export types. ## Changes - **Added `scripts/fix-dts-imports.cjs`**: Post-build script that adds `.js` extensions to all relative imports in generated `.d.ts` files - Handles `import` statements - Handles `export` statements - Handles dynamic `import()` type expressions - **Updated `package.json`**: - Added `build:fix-dts` script to run the DTS fixer - Updated `build` script to include the fix-dts step - Added `attw` script for type validation using `@arethetypeswrong/cli` - Updated `integrity-checks` to include `attw` validation ## Verification **Before fix** (using `@arethetypeswrong/cli --pack`): - ❌ **InternalResolutionError** - Module resolution failed (breaking bug) **After fix**: - ✅ **No problems found** - All module resolution working correctly ⭐ - ✅ Declaration files now have `.js` extensions on all relative imports - ✅ Type validation passes with `@arethetypeswrong/cli` ## Test Plan - [x] Build completes successfully with new fix-dts step - [x] Declaration files now have `.js` extensions on all relative imports - [x] `@arethetypeswrong/cli` validation passes (no problems found) - [x] All 166 tests pass without modification - [x] TypeScript compilation succeeds without errors Applies same fix as: - Doist/todoist-api-typescript#410 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: Claude <noreply@anthropic.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Summary
Fixes #407
This PR resolves the type re-export issue introduced in v6.0.0 (PR #379) where types exported from this package could not be re-exported by consuming packages.
Root Cause
When
package.jsonhas"type": "module", TypeScript treats.d.tsfiles as ESM modules, which require explicit file extensions (.js) for relative imports. The generated declaration files had imports likefrom './todoist-api'instead offrom './todoist-api.js', causing module resolution to fail when other packages tried to re-export types.Changes
scripts/fix-dts-imports.cjs: Post-build script that adds.jsextensions to all relative imports in generated.d.tsfilesimportstatementsexportstatementsimport()type expressionspackage.json:build:fix-dtsscript to run the fixerbuildscript to include the fix-dts stepattwscript for type validation using@arethetypeswrong/clifallback-conditionandfalse-esmrules (known limitations of dual-module packages that don't affect functionality)integrity-checksto includeattwvalidationVerification
Before fix (using
@arethetypeswrong/cli --pack):exportsresolution uses fallback conditions, unlike Node microsoft/TypeScript#50762)After fix:
The critical
InternalResolutionErrorthat prevented type re-exports is now resolved. The remaining warnings are expected for dual-module packages and are safely ignored:"type": "module") while CommonJS implementation has its ownpackage.json. This is intentional for dual-module packages.exportsfield has a known bug where it falls back to thetypescondition. This doesn't affect runtime behavior.Test Plan
.jsextensions on all relative imports@arethetypeswrong/clivalidation passes (no InternalResolutionError)🤖 Generated with Claude Code