Repository navigation
fix: pin tree-sitter-java to the version tree-sitter-groovy pins, so it stays deduped - #909
Merged
Merged
Conversation
…it stays deduped tree-sitter-groovy depends on tree-sitter-java@0.23.4 exactly while the parser asked for ^0.21.0. Two versions npm cannot reconcile, so it nests a second copy under tree-sitter-groovy, and the nested copy's gyp config resolves node-addon-api by a relative path whose ../ count is wrong once nested. It cannot build even with a full toolchain. That is invisible wherever a prebuilt binary exists, because nothing compiles. On linux-arm64 the 0.21.x tree-sitter generation ships no prebuilt core, so the build runs, hits the nested copy and fails outright. Pinning to the same version leaves one hoisted copy. Measured on a clean arm64 VM: before, npm install failed with a toolchain installed; after, it succeeds and the parser produces 39 csv files and 48128 rows on a real Java project, matching macOS exactly. The IR is byte for byte identical to 0.21.0 on real Java and Python projects, so the grammar change is behaviour neutral. A caret range is not enough: ^0.23.4 resolves to 0.23.5 and nests again. The two have to name the same version, which is what the new check in package-contents-test.sh asserts. Verified it fails on the old value. This does NOT make linux-arm64 installable without a compiler. No 0.21.x core ships an arm64 prebuild, and no published tree-sitter-java or tree-sitter-groovy accepts a core above 0.21.x, so there is no version set that reaches one. arm64 still needs build-essential; this only removes the failure that a toolchain could not fix. Refs #901
Contributor
Author
|
Correction to the note above: this is no longer held with the engine batch and merges on its own. It is independent of #904 (three files, none of them the executor), it fixes a defect that is on main today, and it is a prerequisite for validating anything else on arm64, because without it the install fails before an engine is ever resolved. Holding it would have blocked the validation it enables. #904 and #902 still merge together once the engine work is complete. |
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.
Refs #901. Merges on its own, ahead of the engine work: it fixes a defect that is on main today and blocks arm64 validation of everything else.
The defect
tree-sitter-groovydepends ontree-sitter-java@0.23.4exactly while the parser asked for^0.21.0. npm cannot reconcile the two, so it nests a second copy undertree-sitter-groovy, and that nested copy's gyp config resolvesnode-addon-apiby a relative path whose../count is wrong once nested:It is invisible wherever a prebuilt binary exists, because nothing compiles. On linux-arm64 the 0.21.x generation ships no prebuilt core, so the build runs and fails on the nested copy.
Measured on a clean arm64 VM
The 39 files and 48128 rows match macOS exactly. On real Java and Python projects the IR is byte for byte identical to
tree-sitter-java@0.21.0, so the grammar change is behaviour neutral and not only install neutral.Why it should not wait for the engine batch
It is independent: three files, none of them the executor, and it does not depend on #904. It is also a prerequisite for validating anything else on arm64, since without it the install fails before an engine is ever resolved.
Why an exact pin
A caret range does not dedupe:
^0.23.4resolves to 0.23.5 while groovy pins 0.23.4, and npm nests again. The two have to name the same version.package-contents-test.shnow asserts the parser's version equals the onetree-sitter-groovypins, and was verified to fail on the old value.What this does not fix
linux-arm64 still needs
build-essential. No 0.21.xtree-sittercore ships an arm64 prebuild, and every publishedtree-sitter-javaandtree-sitter-groovydeclarespeerDependencies { tree-sitter: ^0.21.1 }, which pins the minor on a 0.x version, so no version set reaches an arm64 core prebuild.Bumping the core to 0.22.4 was tried and abandoned. It resolves only with an npm
overridesentry, and overrides apply at the root of an install, so it never reaches a consumer: npm hoists tree-sitter 0.21.1 to satisfy the grammars' peers and installs 0.22.4 nested for us, leaving the consumer on the 0.21.1 that has no arm64 prebuild. That was only caught by testing a consumer-shaped install after the repo install looked clean. It also required migrating fourLanguage.querycall sites that 0.22 removed.Closing the remaining gap needs upstream: an arm64 prebuild for a 0.21.x core, or grammars that accept a newer core. #901 stays open for that.