Repository navigation
linux-arm64: npm install fails, no arm64 prebuilds in the 0.21.x tree-sitter generation and a nested duplicate that cannot build #901
Description
Activity
Partial fix in #909, and one of the two causes turns out not to be fixable from here.
Fixed: the nested duplicate. Pinning tree-sitter-java to 0.23.4, the version tree-sitter-groovy pins exactly, leaves one hoisted copy. On a clean arm64 VM the install previously failed even with build-essential; it now 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 does not work:
^0.23.4resolves to 0.23.5 and nests again, so the pin has to be exact, andpackage-contents-test.shnow asserts that and fails on the old value.Not fixable from here: arm64 without a compiler. No 0.21.x tree-sitter core ships an arm64 prebuild, and every published tree-sitter-java and tree-sitter-groovy declares
peerDependencies { tree-sitter: ^0.21.1 }, which on a 0.x version pins the minor. There is no version set that reaches an arm64 core prebuild while satisfying the grammars.The core bump to 0.22.4 was tried and abandoned. Two reasons, both measured:
- It only resolves with an npm
overridesentry, and overrides apply at the ROOT of an install. A consumer installing the tarball gets tree-sitter 0.21.1 hoisted to satisfy the grammars' peers and 0.22.4 nested for us, so the consumer still lands on the 0.21.1 that has no arm64 prebuild. The repo install looked perfect and the VM still failed, which is the only reason this was caught. - It needs a parser migration: 0.22 removed
Language.query, so four call sites move tonew Parser.Query(language, source), and the grammars' ownLanguagetype stops matching the core's. That work is done and verified (build clean, IR identical, all four grammars load and parse under 0.22.4) but it buys nothing while point 1 stands, so it is not in fix: pin tree-sitter-java to the version tree-sitter-groovy pins, so it stays deduped #909.
Closing the gap needs upstream: an arm64 prebuild for a 0.21.x core, or grammars that accept a newer core. Until then linux-arm64 needs build-essential, which is worth stating in the install docs rather than leaving users to find it through a node-gyp trace.
Leaving this open for that.
- It only resolves with an npm
npm installof the published package fails outright on linux-arm64. The engine half is fine; the install never reaches it.Symptom
On a clean arm64 machine with node and nothing else:
Installing a full build toolchain does not fix it. The failure moves to a nested copy and becomes:
Two causes
No arm64 prebuilds in the 0.21.x generation. Every native dependency falls back to node-gyp, which needs a compiler the user does not have.
A nested duplicate that cannot build.
tree-sitter-groovypinstree-sitter-java@0.23.4exactly while the parser asks for^0.21.0. The two ranges cannot both be satisfied, so npm nests a second copy, and the nested copy's gyp config resolvesnode-addon-apiby a relative path whose../count is wrong once nested. This is why a toolchain does not help. A caret range is not enough to dedupe either:^0.23.4resolves to 0.23.5 and nests again. The pin has to match exactly.Proposed fix
tree-sitter-java@0.23.4declarespeerDependencies { tree-sitter: ^0.21.1 }, so the grammar does not require a core past what is already pinned.Risk
This changes which grammar the parser uses for Java and Python, so it is a correctness change and not only a packaging one. The parser suites need to run against the new grammars before it lands, and any IR difference has to be explained rather than blessed.
Scope
Pre-existing, independent of the engine packaging. Other platforms are unaffected: linux-x64, darwin-arm64, darwin-x64 and win32-x64 all install today from prebuilds with zero node-gyp runs.