Allow publishing of pre-release version

Issue

When utilizing the semantic-release package's pre-release functionality, the semantic-release-chrome's chrome web api call throws a version format error.

This is preventing me from publishing a new version of my chrome extension to a staging extension while maintaining the pre-release functionality on my develop branch.

• I have searched the issues of this repository and believe that this is not a duplicate.

Your Environment

• semantic-release-chrome version: 3.2.0
• node version: 18.11.15
• npm (or yarn) version: 3.3.0

What you did and problem description

My develop branch was set up as a pre-release branch in the semantic-release release.config. The semantic-release-chrome plugin was also configured within the release.config. I triggered the CD pipeline which resulted in a pre-release version name (such as 1.0.0-develop.1) to be passed to the semantic-release-chrome plugin. This version caused a chrome web store error due to the invalid semantic version format.

What happened

I do not have access to the exact error message at this point. It was something along the lines of an invalid version format error.

Reproduction repository/CodeSandbox

Suggested solution

Add an optional boolean allowPrerelease field to the PluginConfig interface. When allowPrerelease is specified and set to true, the semantic version number is parsed from the given version string instead of using the raw string. For example, if 1.0.0-develop.1 is the given pre-release version, then 1.0.0 will be parsed and used for the chrome web store publishing purposes.

Pull request for this issue can be found here - #112

[hanseltime]

This would be great to have! Especially since Chrome doesn't allow me to control canary releases for an extension and I need a staging extension for QA.

I do think the issue described and the solution might need a little adjustment though. I would propose:

1. We have a branch/prereleaseOverride section in the config

{
  "plugins": [
    [
      "semantic-release-chrome",
      {
        "extensionId": "mppjhhbajcciljocgbadbhbgphjfdmhj",
        "asset": "my-extension.zip",
        "prereleaseConfig": {
           "alpha": {
               "extensionId": "my-alpha-extension-id",
           },
           "beta": {
               "extensionId": "my-beta-extension-id",
           },  
        }.
      }
    ],
    [
      "@semantic-release/github",
      {
        "assets": ["my-extension.zip"]
      }
    ]
  ]
}

The above config feels a little safer to me. If I hard-coded the extension id and added "allowPrerelease", then I could technically still release to my prod extension from my prerelease branch. If we added the ability to configure prerelease channel configs (and then throw errors on any prerelease branch that doesn't have a config), then the releaser has to be sure they are specifying the correct extension.

Also, I think for prerelease, we don't want to scrub the 4th number. That would lead to weird spots where we release 2 or 3 prereleases that are all 1.0.1 and only the first one can release. Looking at the Chrome extension versioning name, it looks like we could just remove the non-numerical prerelease name (like alpha or beta) and just release that number.

Source: https://developer.chrome.com/docs/extensions/reference/manifest/version

[RupertBarrow]

Yes.
For prerelease, I would certainly expect a 4-number version number such as 1.0.0.1

[RupertBarrow]

It would be great for this plugin to update the "version_name" field in the manifest.json with the "standard" version name normally generated by semantic-release, such as "1.0.0-alpha.1"

[envil]

It would be great for this plugin to update the "version_name" field in the manifest.json with the "standard" version name normally generated by semantic-release, such as "1.0.0-alpha.1"

Exactly, "version_name" can be used exclusively for prerelease.