search

gleam-lang / tree-sitter-gleam

🌳 A tree-sitter grammar for the Gleam programming language
Apache License 2.0
66 stars 13 forks source link

Updates for v0.28.0 #55

Closed J3RN closed 1 year ago

J3RN commented 1 year ago

There's a lot here, but then again a lot changed!

Each commit is a self-contained unit, please view them individually to retain your sanity :grin:

J3RN commented 1 year ago

I wanted to update on the status of this PR. Currently it's failing the integrations suite, because some of the code therein isn't Gleam v0.28.0 compliant. There are (at least) three roads forward:

  1. Try to update the offending projects. I started this approach, invested a few hours, but ultimately didn't get very far.
  2. Remove the offending projects from our integration suite (for now, at least)
  3. Make tree-sitter-gleam backwards-compatible. I historically have versioned tree-sitter-gleam the same as Gleam versions, meaning that if you're using Gleam v0.27.0 (e.g.), then you should use tree-sitter-gleam v0.27.0. This simplified a number of things, e.g. backwards-compatibility was irrelevant and we could rename nodes to match the Gleam parser as its own nodes were renamed. It may be worthwhile reconsidering this approach, but it also entails new issues.

Feedback here welcome 😁

the-mikedavis commented 1 year ago

I was curious about that with some of the changes from 0.30 like removing the 'external' from external types. I think it would be ok to be more permissive about deprecated / removed syntaxes. We could have some policy like keeping around old syntaxes for a few versions and eventually dropping them, since maintaining deprecated code forever is a big pain.

For the integration tests though I think we could also limit the set of repos to those that are usually up-to-date soon after syntax changes, just to minimize the maintenance burden.

lpil commented 1 year ago

Agreed! Keeping them around for at least long enough for the community to largely have moved over would be good. Currently Gleam supports both syntaxes, and I think it'd make sense for tooling to support both for longer still.