fix: module issues with types #212
Merged
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
toddbaert
changed the title
toddbaert
changed the title
Fix runtime issues with types in ES module projects Signed-off-by: Todd Baert <[email protected]>
toddbaert
force-pushed
the
fix/bundling-issues
branch
from
b485b46 to
3edf839
Compare
toddbaert
commented
Jan 19, 2023
Signed-off-by: Todd Baert <[email protected]>
tcarrio
approved these changes
Jan 19, 2023
toddbaert
commented
Jan 19, 2023
Signed-off-by: Todd Baert <[email protected]>
Merged
This was referenced Jul 12, 2023
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.
Fixes an issue with imports in ES module projects. Specifically, in some TS configurations, compilation would fail because TS esm support requires file extensions on all imports. Though our code is bundled, our declaration files are not, and they are also subject to this requirement. To avoid having to add
.jsextensions in our rendered type files, this adds a package.json withtype: commonjsonly in the type file roots, making them behave as commonjs modules, (which don't require file extensions in imports).I attempted first to bundle all our types into a single d.ts (to avoid imports entirely), but was unable to find a decent solution to that.
Fixes: #198
I've tested this fix with the example repo in the linked issue, as well as another es-module project, and a commonjs project. Everything works as expected.