Skip to content

refactor: switch to official go tree-sitter implementation #2952

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

jbedard
Copy link
Contributor

@jbedard jbedard commented Jun 2, 2025

The https://github.com/smacker/go-tree-sitter library seems dead and we should switch to the official https://github.com/tree-sitter/go-tree-sitter. I know there's already a lot of discussion around tree-sitter in rules_python/gazelle, I thought I should bring this into the discussion as well. This PR depends on even more patches then what https://github.com/dougthor42/go-tree-sitter is patching, I'm not sure how you want to deal with that going forward (I've found the latest rules_go solves 50% of it).

The official library has been properly maintained for some time now and has a lot of features that the smacker version is lacking. I was able to delete a decent amount of code in the js/ts gazelle extension when switching (such as all predicate filtering which is properly implemented in the official go-tree-sitter).

@jbedard jbedard requested review from dougthor42 and aignas as code owners June 2, 2025 22:45
@@ -17,14 +17,25 @@ local_path_override(

go_deps = use_extension("@bazel_gazelle//:extensions.bzl", "go_deps")
go_deps.from_file(go_mod = "//:go.mod")
go_deps.module_override(
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is, sadly, a blocker because overrides cannot be used in non-root modules.

If this is included, then no one can add the dep via:

# MODULE.bazel
bazel_dep(name = "rules_python_gazelle_plugin")

As it will fail with:

Using the "go_deps.{tag_class}" tag in a non-root Bazel module is forbidden

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You can fork that library as well if you want, or ask users to add these 3 lines themselves. I'm just opening this PR to suggest using the modern go-tree-sitter library...

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm 100% for using the modern go-tree-sitter library. I just think we are blocked from doing so until bazel-contrib/rules_go#4298 is released and we update our rules_go version.

Otherwise we get stuck in the "users must apply a patch themselves" or "we have to maintain a fork" situation that we're already in.

I think the path forward is:

  1. Wait for rules_go to release the fix.
  2. Update rules_go
  3. Remove the dougthor42/go-tree-sitter hack and go back to smacker/go-tree-sitter
  4. Migrate to the official tree-sitter repos.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think bazel-contrib/rules_go#4298 fixes every scenario. After upgrading to rules_go@HEAD I was able to remove my patch to smacker/go-tree-sitter, but when switching to tree-sitter/go-tree-sitter I had to add almost the same patch again 😢

patch_strip = 1,
)
go_deps.module_override(
path = "github.com/tree-sitter/tree-sitter-python",
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One alternative to patching the tree-sitter-* libraries (with the bindings/go/bindings.go file) is generating a single BUILD ourselves like what I've done in the aspect-cli, see the http fetch+BUILD and associated go.

That's probably nicer then a patch now that I look at it again...?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Using go modules works better when mixing go modules across multiple modules though, such as multiple gazelle languages from different modules. But that requires the patches :/

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Making the BUILD file ourselves is basically what the dougthor42/go-tree-sitter does.

Does manually setting http_archive.build_file_content work with both WORKSPACE and bzlmod? If so that might be a way forward. I agree it's cleaner than the patches.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is only for the tree-sitter-{lang}/bindings/go/bindings.go files, not the main go-tree-sitter go module that has the bigger problem.

@@ -17,14 +17,25 @@ local_path_override(

go_deps = use_extension("@bazel_gazelle//:extensions.bzl", "go_deps")
go_deps.from_file(go_mod = "//:go.mod")
go_deps.module_override(
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm 100% for using the modern go-tree-sitter library. I just think we are blocked from doing so until bazel-contrib/rules_go#4298 is released and we update our rules_go version.

Otherwise we get stuck in the "users must apply a patch themselves" or "we have to maintain a fork" situation that we're already in.

I think the path forward is:

  1. Wait for rules_go to release the fix.
  2. Update rules_go
  3. Remove the dougthor42/go-tree-sitter hack and go back to smacker/go-tree-sitter
  4. Migrate to the official tree-sitter repos.

patch_strip = 1,
)
go_deps.module_override(
path = "github.com/tree-sitter/tree-sitter-python",
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Making the BUILD file ourselves is basically what the dougthor42/go-tree-sitter does.

Does manually setting http_archive.build_file_content work with both WORKSPACE and bzlmod? If so that might be a way forward. I agree it's cleaner than the patches.

version = "v0.23.1",
)
go_repository(
name = "com_github_tree_sitter_tree_sitter_rust",
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why does this need all of the non-python languages?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think it needs any of them, but they are there, I think just for tests AFAICT.

I don't think we should care. That's how go.mod works, and deps.bzl is how (legacy) rules_go works.

@jbedard
Copy link
Contributor Author

jbedard commented Jun 3, 2025

FWIW I might be blocked on tree-sitter/go-tree-sitter#32 for now so your plan upgrading rules_go and dropping the fork is probably still the next best step.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants