A few feature ideas and whether upstream would be interested in accepting them?

[mikn]

Hi!

Love the project! It is the only "local first" dependency management tool that I have found. Funny how "shift-left" stopped at CI otherwise in this particular use-case.

Anyway, I have some feature ideas that I would gladly contribute:

• A BCR (Bazel Central Registry) Filter
• Ability to create predefined patterns supported both in version matching and in pipeline, perhaps switching to Grok or even a proper lexical parser like PEG instead of just pure regex
• Pass NAME as the name of the rule instead of the version (breaking change), this would allow for expanding the name of the rule into the pipeline
• Support file-level patterns
• The ability to run language specific tooling to generate the file diff
• More advanced PR creation logic

To expand on each:

BCR Support

We use Bazel, I have already made the filter to support bcr: syntax, not much more to say. :)

Predefined patterns -> Switch Lexer

This would allow for creating a library of patterns, like for instance the regexp for semver is relatively complicated and it is a bit annoying to have to repeat it for every instance you need to use it. Currently I assume most people opt for a simpler than comprehensive pattern, but then it is also be annoying to have to change the pattern if you all of a sudden want to install the -pre1 version instead of the regular one.

Principally, I would prefer PEG, as it is more robust, has better multiline support and most languages and file formats have a PEG grammar defined. I can however see that Grok patterns would be a smaller step away from the current regex-based pipeline syntax that exists today and therefore I would love to hear your thoughts on this.

Passing down the rule name instead of the version as name

This would be more intuitive, that the key named name is actually the rule name, but also it would allow to create higher level patterns that would match multiple lines and do great. (i.e a powerful feature to enable "file-level patterns")

File-level patterns

What I mean with this is that in the Bumpfile you can prefix a whole file with a pattern or a series of patterns, and together with predefined patterns and passing down the rule name, you could easily make a very nice oneliner like this:

bazel_dep %{BCR}|@VERSION.MAJOR^
MODULE.bazel

here the syntax is group_name %{GROK_PATTERN} where grok_pattern could expand to the whole pipeline like this: %{BAZEL_DEP:NAME} /(%{SEMVER:VERSION}/ bcr:@NAME This could also expand into the "link" and perhaps changelog parsing also.

Language-specific tooling

A lot of languages comes with pretty good, project level dependency update mechanisms, like rust comes with cargo update, python has things like pip-update etc. The good ones also allow you to "pin" versions directly in the dependency declaration file, similar to your pipeline implementation, but not all of them (I am looking at you golang). Bump would in some cases just straight up run the update command without further ado to generate the diff and in other cases it would have to intervene (unsure how) to augment the current update behaviour to allow for semver pinning. In all cases it would have to understand the tool output however and interrogate the tool for changelogs and project links. This would be an extension of file-level patterns as I see it.

This would allow bump to own the entire version updating flow for a monorepo instead of me having to use bump for some things, then some nasty wrapper script for each language that we have that has good native support. I would love to keep the Bumpfile and having to explicitly list each file that it manages still, this would just be another "group pattern" as I see it.

PR Creation logic

Here, for us, we would love to have the ability to do more advanced flows, like only having a single "update" branch active at a time and let it accumulate changes instead of one per bump run. This would really set bump apart from other very PR-creation-happy workflows, like dependabot and renovate.

We manage hundreds of software versions in our monorepo across 10s of file formats and, whilst using bump today would be a bit of a nightmare in terms of verbosity, I think these changes would together create an amazing version update tool that would also work for surprisingly large monorepos and allow for even nicer UX for smaller projects also.

[wader]

Hi!

Love the project! It is the only "local first" dependency management tool that I have found. Funny how "shift-left" stopped at CI otherwise in this particular use-case.

Thanks! Yeap I wanted something that would be nice both manually and via automation... and also nice while developing :)

Anyway, I have some feature ideas that I would gladly contribute:

• A BCR (Bazel Central Registry) Filter
• Ability to create predefined patterns supported both in version matching and in pipeline, perhaps switching to Grok or even a proper lexical parser like PEG instead of just pure regex
• Pass NAME as the name of the rule instead of the version (breaking change), this would allow for expanding the name of the rule into the pipeline
• Support file-level patterns
• The ability to run language specific tooling to generate the file diff
• More advanced PR creation logic

To expand on each:

BCR Support

We use Bazel, I have already made the filter to support bcr: syntax, not much more to say. :)

Great! open a PR. Should be a quite straight forward filter I guess?

Predefined patterns -> Switch Lexer

This would allow for creating a library of patterns, like for instance the regexp for semver is relatively complicated and it is a bit annoying to have to repeat it for every instance you need to use it. Currently I assume most people opt for a simpler than comprehensive pattern, but then it is also be annoying to have to change the pattern if you all of a sudden want to install the -pre1 version instead of the regular one.

Principally, I would prefer PEG, as it is more robust, has better multiline support and most languages and file formats have a PEG grammar defined. I can however see that Grok patterns would be a smaller step away from the current regex-based pipeline syntax that exists today and therefore I would love to hear your thoughts on this.

TIL grok pattern, nice idea. Yeap that makes a lot of sense for both version matching and in a pipeline. So something like NAME /Version=%{SEMVER}/ PIPELINE?

Not sure I followed fully about PEG. That would require a runtime PEG parser and matcher I guess? so there would be both pre-defined and user defined PEG grammars somehow? this will also be for both version match and in pipelines?

Maybe we can come up with some example configs of how it would look like?

Passing down the rule name instead of the version as name

This would be more intuitive, that the key named name is actually the rule name, but also it would allow to create higher level patterns that would match multiple lines and do great. (i.e a powerful feature to enable "file-level patterns")

Possible to somehow give an example how a higher level pattern that matches multiple lines would work? Yeap the key stuff in bump pipelines are not very intuitive and I think I had some greater plan for it but I can only remember that I ended up mostly using it to pass long extra data that could potentially survive thru a filter and be used later on, eg the commit hash for a tag.

File-level patterns

What I mean with this is that in the Bumpfile you can prefix a whole file with a pattern or a series of patterns, and together with predefined patterns and passing down the rule name, you could easily make a very nice oneliner like this:

bazel_dep %{BCR}|@VERSION.MAJOR^
MODULE.bazel

here the syntax is group_name %{GROK_PATTERN} where grok_pattern could expand to the whole pipeline like this: %{BAZEL_DEP:NAME} /(%{SEMVER:VERSION}/ bcr:@NAME This could also expand into the "link" and perhaps changelog parsing also.

In this case bazel_dep would be something that find name and version of dependencies from a bazel config? (sorry, haven't used bezel much myself)

Sounds like a good idea. Long time ago I did experiment a bit with a "next generation" of bump that was more flexible with finding dependencies to track, like reading cargo.toml, go.mod etc. But then the idea was to more or less replicate the logic per package system how it would find possible new versions. As you mention below another way could be to somehow use existing tooling for this but yes you would have parse some output etc.

Language-specific tooling

A lot of languages comes with pretty good, project level dependency update mechanisms, like rust comes with cargo update, python has things like pip-update etc. The good ones also allow you to "pin" versions directly in the dependency declaration file, similar to your pipeline implementation, but not all of them (I am looking at you golang). Bump would in some cases just straight up run the update command without further ado to generate the diff and in other cases it would have to intervene (unsure how) to augment the current update behaviour to allow for semver pinning. In all cases it would have to understand the tool output however and interrogate the tool for changelogs and project links. This would be an extension of file-level patterns as I see it.

This would allow bump to own the entire version updating flow for a monorepo instead of me having to use bump for some things, then some nasty wrapper script for each language that we have that has good native support. I would love to keep the Bumpfile and having to explicitly list each file that it manages still, this would just be another "group pattern" as I see it.

That would be nice. But would that update all version at once? One thing I like about bump is to be able to create PRs that are separate per dependency to minimize changes when running CI tests etc.

Aren't golang dependencies always "pinned" kind of or do you mean there is no explicit constraint config?

PR Creation logic

Here, for us, we would love to have the ability to do more advanced flows, like only having a single "update" branch active at a time and let it accumulate changes instead of one per bump run. This would really set bump apart from other very PR-creation-happy workflows, like dependabot and renovate.

We manage hundreds of software versions in our monorepo across 10s of file formats and, whilst using bump today would be a bit of a nightmare in terms of verbosity, I think these changes would together create an amazing version update tool that would also work for surprisingly large monorepos and allow for even nicer UX for smaller projects also.

All this in bump is a bit of a hack at the moment. Sadly the development environment when testing GitHub actions are not very nice. If you digg into this I would recommend trying to replicate the action run environment (think I used docker a lot) or do tests, and just lastly actually test using the real GitHub API. Debugging using real action runs is very time consuming.

Yes accumulate changes and possible also rerun on conflicts somehow would be great, I have some repos where bump PRs have started to pile up when something is blocking :) One tricky thing might be how to model things in PRs to make it possible. One rule will reuse same branch name?

Any idea how such PR create flow configs would look like?

To summarize: I'm very happy bump is being useful and all nice and good idea that I would like to have also. I'm not sure how much time and energy I have to work on it myself at the moment, but I'm happy to talk ideas (can even have video call if you want), review code and so on.