[web-tree-sitter] Fix type definitions in exports…#4229
Merged
ObserverOfTime merged 1 commit intotree-sitter:masterfrom Jun 15, 2025
Merged
Conversation
|
Confirming I experienced the issue in #4228 and that this PR fixes it for me. In the meantime as workaround I just used |
amaanq
approved these changes
Apr 19, 2025
f9f8c11 to
fc8ddd3
Compare
…and generate `.d.cts` files for CommonJS exports.
fc8ddd3 to
8476c94
Compare
|
Backport failed for Please cherry-pick the changes locally and resolve any conflicts. git fetch origin release-0.25
git worktree add -d .worktree/backport-4229-to-release-0.25 origin/release-0.25
cd .worktree/backport-4229-to-release-0.25
git switch --create backport-4229-to-release-0.25
git cherry-pick -x 02fff92b91fbb60cab1ff7691163c6019b408e05 |
Member
|
Looks like some previous related change didn't make it in 0.25 so this can't make it either. |
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
4 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.
…and generate
.d.ctsfiles for CommonJS exports.Fixes #4228, though someone might want to verify that with actual testing in TypeScript.
The current structure of
"exports"inpackage.jsonis incorrect; this TypeScript blog post details how it ought to look, and reminds us that the"types"field must come before the"default"field.Arethetypeswrong gives us a good grade here, if not an A+:
The “Resolution failed” there is because
node10is the oldest TypeScript resolution algorithm, one which predates the invention of the"exports"field inpackage.json. If we absolutely wanted the extra credit here, we could copy the.d.tsand.d.ctsfiles into thedebugfolder, but I'm not sure it's even worth doing.Once I changed the format of the
"exports"field, arethetypeswrong chided me for having one.d.tsfile — an ESM module's type definition, since we do"type": "module"inpackage.json— pulling double duty as also documenting the.cjsfile. This is supposedly bad for the reasons explained here; and if someone writes decent prose in an authoritative voice, I tend to believe it.To fix this, I'm having the
build:dtstask generate both.d.tsand.d.ctsfiles at once. This felt more elegant than just copying one file to the other destination on a build, especially since the corresponding.mapfiles reference specific file names.To test, I just recapitulated the steps in the CI workflow locally, ran
npm pack, and gave arethetypeswrong the resulting.tgz. I may or may not get around to testing in an actual dummy TypeScript project.