chore(deps): Update tree-sitter dependencies to versions supporting Node 20

[cr7pt0gr4ph7]

This PR upates the different tree-sitter dependencies to versions that are compatible with Node 19/20.

Background

The previously used version 0.20.x of tree-sitter (the exact version number depends on the specific tree-sitter-* sub-package) does not work on Node 19 and higher, leading to errors like the following:

Request initialize failed with message: bad export type for `tree_sitter_(tsx|csharp|typescript|...)_external_scanner_create`: undefined (Internal Error)

This broke e.g. the Official Cucumber VS Code extension when VS Code updated to a newer version of Node 19 (and later Node 20) that was not supported at the time by the tree-sitter library, but support has since been implemented and subsequently shipped in tree-sitter v0.21.0 and above.

Should fix the bad export type for ... error once the updated version is included cucumber/language-server and then cucumber/vscode that has been reported at least a couple times:

• Fixes Can't start language server from Emacs language-server#102
• Fixes Server initialization failed. vscode#234
• Fixes Cucumber on working on windows WSL vscode#243
• Fixes Language Server Client couldn't create connection to server vscode#247
• Fixes Failure to start extension under latest VS Code  vscode#155

Sidenote on versioning & compatibility of tree-sitter

The versioning and release scheme of the tree-sitter libraries is a bit "messy": The tree-sitter-typescript/tree-sitter-rust/... sub-libraries have a strong dependency on the major version number of tree-sitter, such that versions of the component libraries that require different major versions of the tree-sitter library cannot be used together. But they are:

• Not released at the same time.
• Do not have an central versioning number scheme.
• Introduce incompatible dependency upgrades from one patch version to the next (e.g. [email protected] requires [email protected] while [email protected] requires [email protected]).

(though that does not strictly violate SemVer requirements due to still being a 0.x.y development version).

The approach taken here was to look for the newest version of tree-sitter for which all sub-libraries have at least one compatible release (which came out to be [email protected]) and to choose the newest version of each sub-library that still supports [email protected] (which eliminated a few of the most recent releases).

Related PRs

This PR subsumes/replaces #225 as well as the following automated PRs (which have build failures due to trying to update the different dependencies separately):

• chore(deps): update dependency tree-sitter-php to v0.23.11 #180
• chore(deps): update dependency tree-sitter-ruby to v0.23.1 #183
• chore(deps): update dependency tree-sitter-cli to v0.24.6 #184
• fix(deps): update dependency web-tree-sitter to v0.24.6 #185
• chore(deps): update dependency tree-sitter to v0.22.4 #188 (tree-sitter updated to 0.21.1 instead of 0.22.1 due to compatibility requirements, see below)
• chore(deps): update dependency tree-sitter-python to v0.23.6 #189 (tree-sitter-python updated to 0.23.4 instead of 0.23.6 due to compatibility requirements, see below)
• chore(deps): update dependency tree-sitter-go to v0.23.4 #201
• chore(deps): update dependency tree-sitter-java to v0.23.5 #234

Tests

Tested with a custom build of cucumber/vscode to work on my current VS Code version:

Version: 1.95.3
Commit: f1a4fb101478ce6ec82fe9627c43efbf9e98c813
Date: 2024-11-13T14:50:04.152Z
Electron: 32.2.1
ElectronBuildId: 10427718
Chromium: 128.0.6613.186
Node.js: 20.18.0
V8: 12.8.374.38-electron.0
OS: Linux x64 6.11.3-300.fc41.x86_64

A note on "missing import symbols" errors

If there are issues with missing import symbols (namely missing symbol 'abort' from module 'env') after this update, this is due to a (too old) version of emscripten being used to compile tree-sitter to WASM.

The solution in that case is to install a newer version of emscripten.

• tree-sitter currently uses emscripten v3.1.64
• My development environment used emscripten v3.1.74

[cr7pt0gr4ph7]

@kieran-ryan Test failures should be fixed now (npm test completed successfully when I ran it on my machine just now).

[kieran-ryan]

@kieran-ryan Test failures should be fixed now (npm test completed successfully when I ran it on my machine just now).

Thanks a bunch for the contribution first and foremost @cr7pt0gr4ph7 - and for a well-documented pull request; will be super to have this issue resolved! Will look to fully test and review soon as I can - as time allows off on the back of holidays. Checking, are you testing on Windows by any chance; or any other other detail you can provide on your runtime? Will try to replicate difference in test outcome between running locally and the pipeline. There are some disparities in testing with the project which require resolution at some point to improve the contributing experience.

Suspect failing due to instability of query specifiers in tree-sitter language implementations (at least very early versions pinned in the package) which may have changed since with these updates - see tree-sitter-rust #226 for reference of associated changes. May not be the case, though was anticipating query changes with these upgrades.

Tree-sitter's live playground can be used to check the query and test data associated with a language-implementation for compatibility - compared to the older versions our queries were compatible with; though you may want to run a local tree-sitter playground against the specific language implementation versions you are running locally for accuracy as they may differ.

[cr7pt0gr4ph7]

Edit: @kieran-ryan Problem solved - I commited the query fixes but didn't push them. Oops 😅

---

Checking, are you testing on Windows by any chance; or any other other detail you can provide on your runtime?

I'm running on Linux Bluefin (Fedora-based) inside a Docker container:

$ uname --all
Linux a8f8f4bfa59d 6.11.3-300.fc41.x86_64 #1 SMP PREEMPT_DYNAMIC Thu Oct 10 19:18:36 UTC 2024 x86_64 GNU/Linux

$ node --version
v22.12.0

Will try to replicate difference in test outcome between running locally and the pipeline. There are some disparities in testing with the project which require resolution at some point to improve the contributing experience.

I'll have a look at the failed tests. (Edit: Solved, see above).

Suspect failing due to instability of query specifiers in tree-sitter language implementations (at least very early versions pinned in the package) which may have changed since with these updates - see tree-sitter-rust #226 for reference of associated changes. May not be the case, though was anticipating query changes with these upgrades.

The test failures which I could observe locally were partially due to syntax tree changes in tree-sitter-csharp. I'll have a look! (Edit: Already fixed, see above).

Tree-sitter's live playground can be used to check the query and test data associated with a language-implementation for compatibility - compared to the older versions our queries were compatible with; though you may want to run a local tree-sitter playground against the specific language implementation versions you are running locally for accuracy as they may differ.

Thanks for the pointer! I actually looked for a Tree-sitter playground, but Google did not provide any helpful results. The manual page you linked does not even appear on the first page of results...

[cr7pt0gr4ph7]

@kieran-ryan Regarding further testing: I'd probably suggest updating cucumber/vscode first, and then wait for some time to if any additional problems are reported. It can't get any more broken than it is right now (where the language server doesn't even start in VS Code).