Upstreaming generation of bindings

[amaanq]

Hi! Very cool project - I have to say that it's nice to see Go getting support for tree-sitter. I'm a member of the upstream tree-sitter org, and I'd like to include go bindings via the cli when creating/generating a grammar, though not by default. I plan to add C, Swift, and Go, and Swift/Go can be enabled in package.json with a "bindings" field or so (still working it out atm).

Would you be okay with me upstreaming this behavior? Obviously I'd be basically copying your binding.go/binding_test.go files pretty much.

Thanks!
Amaan

[smacker]

Hello @amaanq ! Sure! That would be great.

I would also really appreciate it if you could ping me when the work is done, so I could update the repository to use upstream grammar bindings.

[amaanq]

There might be a slight misunderstanding - I'm aware that CGo is used to create ffi bindings to go (in bindings.go), and that would be kept here, however, a grammar's bindings/export of its language function would functionally be upstreamed. Hopefully I didn't cause any sort of misunderstanding

[amaanq]

Ideally, tree-sitter will bundle binding/binding_test.go for a language, and a go.mod file, but for go.mod I'm unsure how we should format this.

Here's my current take

module github.com/tree-sitter/tree-sitter-LANGUAGE_NAME

go 1.20

require github.com/smacker/go-tree-sitter v0.0.0-20230720070738-0d0a9f

See here for rust/js implementations (cargo.toml and package.json)

https://github.com/tree-sitter/tree-sitter/tree/master/cli/src/generate/templates

[amaanq]

Ok, see here:

tree-sitter/tree-sitter#2438

[amaanq]

@smacker on another note I'd like to also upstream this repo, and would of course invite you as a maintainer of that repo w/ full access (for just that repo)

Having very popular bindings be upstream makes it much easier for people wanting to use them to find, and I would also like to add many new API bindings that are not here, like I've done in Python in this PR:

tree-sitter/py-tree-sitter#150

Feel free to decline, there's no pressure at all! Though it'd be awesome if you were okay with this 😁 and I think there's 0 downsides with a lot of upsides :)

[ObserverOfTime]

It should be documented that using a parser in your project can be tricky.
You have to add the parser as a submodule and have these in go.mod:

require github.com/tree-sitter/tree-sitter-c v0.21.0
replace github.com/tree-sitter/tree-sitter-c => ./tree-sitter-c/bindings/go