Standard-version: Plugin/preset support could be improved

[eemeli]

With #591 and #638, it's clear that there's interest in using standard-version for other languages than just JavaScript. It would be nice if the core package had better support for implementing this type of support as separate plugins or presets, rather than needing to package those into the core.

As is, the custom updater support is nearly this, but not quite. It needs to be set as a string, and is then required using:
https://github.com/conventional-changelog/standard-version/blob/80301c3b62d7c8f9025def1fce31350a0a03f545/lib/updaters/index.js#L25-L27

This means that if an updater were released as e.g. standard-version-preset-rust, it would need to be used with a config like this:

module.exports = {
  packageFiles: [
    {
      filename: 'Cargo.toml',
      updater: 'node_modules/standard-version-preset-rust/cargo.js'
    }
  ],
  bumpFiles: [
    {
      filename: 'Cargo.toml',
      updater: 'node_modules/standard-version-preset-rust/cargo.js'
    },
    {
      filename: 'Cargo.lock',
      updater: 'node_modules/standard-version-preset-rust/cargo-lock.js'
    }
  ]
}

It would be much easier if the config could just be:

module.exports = {
  presets: ['rust']
}

The default preset could then be called 'javascript', and multiple presets as well as custom user-defined updaters could be merged pretty easily.

---

I'm starting to promote use of conventional commits and standard-version inside a larger organisation and would be happy to submit a PR for something like the above, but would prefer to first get a sense for whether this would be a welcome direction for the tool.

[eemeli]

As a possible extension to just defining an updater, a preset should be able to define lifecycle scripts. For example, a Maven preset would probably want to add another commit to the repo in posttag where the pom.xml version is updated to use the next -SNAPSHOT version.

[bcoe]

@eemeli I always felt it would be a good idea to better support other languages/package managers. Early on we added support for bower.json. And there was a time where we supported composer.json, although we rolled this back because the version # is optional for composer.

The team I currently work on develops in 7 languages, and I've built a library similar to standard-version which supports most of them. The approach I took was the concept of "releasers"/"updaters":

• releasers: know the specific files that need to be updated for a given language (see: https://github.com/googleapis/release-please/tree/master/src/releasers).
• updaters: know how to update the specific files (see: https://github.com/googleapis/release-please/tree/master/src/updaters).

A Maven preset would probably want to add another commit to the repo in posttag where the pom.xml version is updated to use the next -SNAPSHOT version.

We made the java releasers detect whether a snapshot release is required. We then create snapshot releases nightly.

[eemeli]

Good to hear!

My thought was to keep the current structure and configurability of standard-version pretty much as-is, but to add in support for a preset to configure the packageFiles and bumpFiles, as well as using the hooks, all in one go. That would make this a minor change, rather than breaking anything.

Perhaps it'd be easiest for me to add a PR showing what I propose, and continuing the discussion that way?

[bcoe]

Perhaps it'd be easiest for me to add a PR showing what I propose, and continuing the discussion that way?

That sounds reasonable .