integrate with Semantic Release

[lemoustachiste]

Hi,

I am using semantic release to publish my package, which means that at build time my package version is always the same (0.0.0-dev).

Would one be able to integrate this easily with semantic-release, to update the version as it is published?

Thanks

[axelpale]

Interesting question. I am not yet familiar with the semantic release but I assume it is a package release tool that automates semantic version increments.

I try to look into it soon. I believe we can work something out.

If you find a solution, please share. I'm happy to write those instructions to the README.

[axelpale]

A plugin for semantic-release might be the way to go. There is a set of configurations for the user of semantic-release, including a sequence of plugins to run.

I think the best position for the version generation of genversion would be just before npm release step. For this, a new plugin semantic-release-genversion needs to be written, released and added to your semantic-release configuration. The plugin should also be able to remove the generated version file after the release, if I understood correctly.

However, I would like to hear your opinion about the position. Is it okay that the genversion's version.js ends up only into npm and not into git? What do you think about the automatic removal of the generated version file after the release?

[lemoustachiste]

Hi @axelpale,

Thanks for the swift response and look into this issue.

For me, not having the version within git is not an issue, we have the release notes published by semantic release, and my package.json already does not reference the version.

The prepare step seems to be the most appropriate indeed.

The plugin should also be able to remove the generated version file after the release

I am not certain what you mean by this.

I gave it some thought over the weekend, and I also find a bit convoluted the fact that you would add some code to the bundle before releasing it. However, if you think about it, that's what the prepare step does (the published package's package.json references the correct version). Which would mean that if you had some code somewhere expecting the same info, that would mean we are addressing the same concern. I am not familiar enough with genversion, does it read directly from the package.json at runtime or is it isolated at bundle time?

What I was initially thinking, before encountering genversion, was to execute a dryRun of semantic-release, potentially via a Rollup plugin (which is the bundling tool I am using), through the JS API: https://github.com/semantic-release/semantic-release/blob/master/docs/developer-guide/js-api.md#javascript-api. After retrieving the next version, use rollup-plugin-replace to inject the version into the bundle. Could this also be compatible with genversion? I guess in that case, what we would need to do is a rollup-plugin-semantic-release, with configuration option: either the string to replace, or add the genversion overlay.

[axelpale]

Thanks for the deeper analysis and background.

Your initial idea of using rollup-plugin-replace might be the way to go due to following reasons:

• Genversion does not replace a placeholder string; it reads the version string from package.json and generates a small js module file which exports the version string. In your case the package.json does not contain the current version string, thus complicating the adaptation of genversion to semantic-release.
• The generated js module can become problematic. It contains the current version string and therefore you probably do not want to commit it to the repository. The pipeline which generates it should therefore also remove it, what is what I meant. But probably just gitignoring src/version.js does the job as well.
• If genversion was being adapted to semantic-release in a way or another, a reference implementation would be needed. Building on rollup-plugin-replace might require configuration but it might provide a good starting point for a genversion-based plugin. A plugin probably would work in similar manner: after the dry-run but before bundling and releasing.
• It also might be so that the configuration needed by rollup-plugin-replace ends up being more simpler to understand and modify than a possible adaptation of genversion. KISS

Therefore I think it is better for you to try something else than genversion for now. There clearly is an unsolved problem that needs a hero with a solution ;)

Nevertheless, you have given me valuable insight on the challenges of the version property in the wild. I would have never guessed there to be root package.json files without current version data.

If you find a solution, I am all ears!

[axelpale]

See the answer by a member of semantic-release. Use of npm hooks probably solves the problem.

[lemoustachiste]

I have found that I was doing this already in a different project

module.exports = {
  'plugins': [
    '@semantic-release/commit-analyzer',
    '@semantic-release/release-notes-generator',
    '@semantic-release/npm',
    '@semantic-release/github',
    ['@semantic-release/exec', {
      // eslint-disable-next-line no-template-curly-in-string
      'publishCmd': 'npm run pacts:publish -- --version=${nextRelease.version}'
    }]
  ]
};

That's for publishing my contract tests, but it gives an idea of how the versioning could be approached. However, this is independent from the build, so I am not sure how you would go about and address that (modify the build code at that moment)?

[axelpale]

Thanks for the approach.

How about adding prepareCmd to exec options? If I understood the docs correctly, those commands would be run during the prepare step of semantic release.

Maybe I should upgrade Genversion to allow feeding in the version string as an argument like below:

module.exports = {
  'plugins': [
    '@semantic-release/commit-analyzer',
    '@semantic-release/release-notes-generator',
    '@semantic-release/npm',
    '@semantic-release/github',
    ['@semantic-release/exec', {
      // eslint-disable-next-line no-template-curly-in-string
      'prepareCmd': 'genversion --useVersion=${nextRelease.version} src/version.js && npm run build',
      // eslint-disable-next-line no-template-curly-in-string
      'publishCmd': 'npm run pacts:publish -- --version=${nextRelease.version}'
    }]
  ]
};

What do you think? Would that work?

[recih]

--useVersion seems nice! Can't believe it still hasn't been implemented after 5 years ;)