build: automate non-npm version updates #130
Conversation
| sed -i Makefile -e 's/^VERSION := .*/VERSION := $(VERSION)/' | ||
| sed -i Cargo.toml -e 's/^version = .*/version = "$(VERSION)"/' | ||
| sed -i pyproject.toml -e 's/^version = .*/version = "$(VERSION)"/' | ||
| git add package.json package-lock.json Cargo.toml pyproject.toml Makefile |
There was a problem hiding this comment.
Is this Makefile generated, or we have 100+ lines of Makefile code now?
Seems like these steps should be npm "scripts" that call node scripts, rather than introducing yet another tool (make) on top of the other tools.
There was a problem hiding this comment.
This Makefile is generated. Upstream has started enhancing parser templates in a big way as part of a more integrated ecosystem.
Mid-term goal (work in progress) is to remove reliance on node and move more functionality into the tree-sitter CLI (so you can do tree-sitter release and get them all updated in sync).
There was a problem hiding this comment.
Is this Makefile generated, or we have 100+ lines of Makefile code now?
Most of it is generated.
Seems like these steps should be npm "scripts" that call node scripts, rather than introducing yet another tool (make) on top of the other tools.
make was already a thing (for make parser/vimdoc.so) and it's more convenient to implement these here than in node.
There was a problem hiding this comment.
Yeah, node is a pain for this kind of stuff.
Ok, my concerns are alleviated.
There was a problem hiding this comment.
However, these additions are in response to my declining to add node tooling just because I cannot figure out how to bump all versions consistently without messing up a git tag. I don't like these either since it pollutes the "C binding layer" with parser management.
Let's wait for upstream to figure this out properly; I'll try to remember to use --no-git-tag-version in the mean time.
There was a problem hiding this comment.
The Makefile can be used for maintenance tasks as well (already had a test target).
There was a problem hiding this comment.
If this is part of the standard generated makefile (which I would advise against; if tree-sitter CLI is required for parser maintenance, one should use that and not offer ten different ways to do the same thing), we'll add it of course. (Can't promise I'll remember to use it, though; see above.)
What I object to is custom changes for this parser only for little gain (in relation to the cost of divergence). Especially if there's already a better approach in the works.
There was a problem hiding this comment.
If this is part of the standard generated makefile
It will be when tree-sitter/tree-sitter#3210 is ready (if the CLI command isn't implemented first).
(Can't promise I'll remember to use it, though; see above.)
You don't have to. npm version will call it automatically.
There was a problem hiding this comment.
Then there's even less need for this PR ;)
|
The tree-sitter CLI will handle version updates in the future. This is a stopgap solution until then. |
This also applies to prereleases for maximum consistency.