Redundant/unnecessary nodes discovered in formatting

[xixiaofinland]

A general thread to put all other items in here.

[xixiaofinland]

it seems soql_query and sosl_query are unnecessary. The direct child has exactly the same content.

  {
    "type": "soql_query",
    "named": true,
    "fields": {},
    "children": {
      "multiple": false,
      "required": true,
      "types": [
        {
          "type": "soql_query_body",
          "named": true
        }
      ]
    }
  },

[xixiaofinland]

I recommend strictly adhering to Semantic Versioning and accumulating breaking changes for the next major release.

This particular change isn't urgent; we can wait to address it along with other potential breaking changes. When the major version number increases, it becomes the users' responsibility to assess and manage the impact of these changes.

[xixiaofinland]

Do you know this pattern?

I'm using release-please combined with conventional commits to automatically manage commits, release, and release notes, such as in this repo

This pattern makes my commit msg much more readable and the release flow professional (at least feels like so) :D

[aheber]

I'm familiar with conventional commits and if everyone that was using this project was doing so through published packages it would probably be a reasonable plan.

Look at Neovim, they have a daily job that checks out the HEAD commit from the repo, tests it, and if the queries they have on file don't explode (doesn't actually confirm other behaviors as far as I know) then they update their commit hash. No amount of versioning on my part will help that process.

The great news is that they have a process, and because we know about it I can trust that they won't really be broken. Sometimes I will have some repair work in cases like these and I'm OK with that. I don't know how many other projects are like that but I suspect several, your project included, that use the repo directly. It helps that you're active and engaged here so you're likely to have a good idea when and why I broke something. I just don't know what I don't know but I do know there are dependents that I don't have any information on. Maybe breaking them regularly will pull them into the public ;)

I still say we embrace breaking changes, I don't think I'm going to follow strict semver practices because there is almost no part of the project that is truly safe to change. Anything that changes the parse tree, including anonymous nodes, could be a breaking change for someone. Maybe the only exception is adding additional named fields. When I changed the modifiers I nested anonymous nodes down a level, that broke my highlighting queries and Neovim's.

For now I'll probably weigh the expected impact of the change. Maybe saying that if I had to update tests it should be a major version? If I'm adding leaf nodes it is usually OK but if I'm taking away or renaming a named node then it is a major bump?

I don't intend to come across not caring but looking at other grammars and tree-sitter itself there seems to be a general acceptance that some of this breakage isn't reasonably avoidable.

I'll look further into the tools you mentioned above, I do need to get more process into this especially building the releases for NPM because right now it is multi-machine and I wouldn't be able to easily add more precompile targets without adding another machine to do the building on. (not unable to solve it, just hasn't been priority)

[xixiaofinland]

I agree, let's embrace the changes. In case ppl build serious applications that heavily rely on your parser, they should have come to the repo and frequently communicated with you already. The risk is low IMO. And even if things really breaked, they will report here :)

[aheber]

We'll follow that for now. I do suspect that I'll need to add more "what to expect with versions" later and build a rule system eventually if I want this library to be trusted.

Today is just not that day, still figuring out what makes the biggest impacts to people and how projects are affected.

I do agree, hopefully if people have invested here they will come and let me know so I can take them into consideration.

[aheber]

I've opted to move these to discussions to create some isolation but also to allow per-message conversations while still keeping the category of changes grouped.

[xixiaofinland]

Makes good sense, everything in one thread is a bad idea, agreed :). I will follow this.