Prebuilt for Electron and Node

[rebornix]

node-tree-sitter is built against all ABI versions, we may want to do the something for languages otherwise we don't have rebuilds for pure Nodejs.

[rebornix]

I think the .travis.yml should be updated as well to pass the build, @maxbrunsfeld any reason why it differs from https://github.com/tree-sitter/node-tree-sitter/blob/master/.travis.yml ?

[maxbrunsfeld]

We had it this way originally, but our Travis CI builds were timing out, because compiling this library takes longer than compiling node-tree-sitter. We need to limit the builds to only use the versions that we really need.

I would suggest maybe keeping Node 8 and 10 (not 9), and not adding Electron 1.6 and 1.7.

[maxbrunsfeld]

@rebornix Just in case you're interested:

Another potential solution to this problem would be for vscode-ruby to switch to using the WebAssembly binding to Tree-sitter. It has almost exactly the same API as node-tree-sitter, and you could completely avoid the issue of ABI/platform differences. You can demo the Ruby parser in the browser here, and there's a bit more info here.

The only downsides I'm aware of are:

• Very old node versions may not have Wasm support (not sure when it landed)
• Parser and Tree instances need to be explicitly deleted by calling .delete(), because WebAssembly won't have GC callbacks until the weakref proposal lands.
• The WebAssembly binding is newer and may have bugs I haven't seen

[rebornix]

@maxbrunsfeld thanks for the quick response! wasm is a decent solution indeed and considering that the majority of VS Code users are using latest few versions of Electron, wasm can be supported nicely.

For native module prebuilt, do you think we can move to N-API from NAN, then we don't need to worry about Node headers. If we target napi version 3 and then we can support Node.js 8.9 and above. For example, I converted node-spellchecker to napi-spellchecker, which solved this issue in another way.

[maxbrunsfeld]

I would love to switch to NAPI. It seems like a fair amount of work, as node-tree-sitter uses a fair number of different V8/node features like async workers, weak references, string manipulation, etc.

If you're interested in opening a PR to convert it, that'd be amazing.

[rebornix]

sure, I'll play with both tree-sitter-ruby and node-tree-sitter to see how easy it is to do the migration and agree, having v8 dependency makes it hard.

[wingrunr21]

@maxbrunsfeld I would be open to switching to the WASM version but I'd like to do it when we are comfortable in its implementation. It would make embedding this in the extension much easier.