afaics it's the standard as defined by semver spec item 7:

if you commit a feature (as in your commit 8afa0458e i.e. "feat(joinnow): add aria label ...") then it's automatically a minor change - which will reset any other index (e.g. the prerelease index).
Indeed, a prereleased version should avoid introducing supplemental (not yet prereleased) feature if you intend to have follow-up prerelease increments with increasing index.

Hence: not a bug ;-)

Yes, however, npm version command does things a bit differently, example:

/c/Users/Ricardo/Downloads/test
❯ npm version major
v2.0.0

/c/Users/Ricardo/Downloads/test
❯ npm version premajor
v3.0.0-0

/c/Users/Ricardo/Downloads/test
❯ npm version premajor
v4.0.0-0

/c/Users/Ricardo/Downloads/test
❯ npm version premajor --preid=sample
v5.0.0-sample.0

/c/Users/Ricardo/Downloads/test
❯ npm version premajor --preid=sample
v6.0.0-sample.0

/c/Users/Ricardo/Downloads/test
❯ npm version prerelease --preid=sample
v6.0.0-sample.1

/c/Users/Ricardo/Downloads/test
❯ npm version prerelease --preid=sample
v6.0.0-sample.2

/c/Users/Ricardo/Downloads/test
❯ npm version prerelease --preid=sample
v6.0.0-sample.3

What's happenning here?

• npm version premajor is always bumping the major version and adding -0 to the end;
• npm version premajor --preid=sample is always is always bumping the major version and adding -sample.0 to the end;
• npm version prerelease is the only command which increments the X in the major.minor.patch-preid.X version.

I'm personally trying to mimic the behavior of npm version premajor --preid=sample with standard-version but I'm not sure it's a functionality currently provided.

standard-version support all of these use case afaik.
e.g. if you repeatedly call npm run release -- --prerelease alpha then you'll get something like 1.0.1-alpha.0, 1.0.1-alpha.1, ... 1.0.1-alpha.x.
you may ommit the preid ("alpha") here as well.
you can even combine with --release-as major|minor|patch ...

@khatastroffik I don't think it supports this use case:

/c/Users/Ricardo/Downloads/test
❯ npm version premajor --preid=sample
v5.0.0-sample.0

/c/Users/Ricardo/Downloads/test
❯ npm version premajor --preid=sample
v6.0.0-sample.0

In words, how can I force bump the major version (for instance) always with preid?

try

standard-version --release-as major -prerelease sample...

Doesn't work for me:

$ npx standard-version --no-verify --skip.tag --skip.changelog --release-as major --prerelease sample
√ bumping version in package.json from 11.0.0-sample.12 to 11.0.0-sample.13
√ bumping version in package-lock.json from 11.0.0-sample.12 to 11.0.0-sample.13
√ committing package-lock.json and package.json

$ npx standard-version --no-verify --skip.tag --skip.changelog --release-as major --prerelease sample
√ bumping version in package.json from 11.0.0-sample.13 to 11.0.0-sample.14
√ bumping version in package-lock.json from 11.0.0-sample.13 to 11.0.0-sample.14
√ committing package-lock.json and package.json

ok. Didn't try it (I'm just a standard user, not a contrib :-)).
Suggestion (worth another try?): standard-version will automatically bump the major if there's a BREAKING CHANGE in one of the comments... Hence:

• ensure there's a BREAKING CHANGE in one of the comments
• call standard-version with the prerelease flag set

Otherwise, you may have to call SV twice in a row:

1. call SV with release-as major + skip...
2. call SV with prerelease flag (and maybe also the --firstrelease flag to avoid another bump)

Haven't tested the first option but it feels like something we don't want to do. As for the second one, tried it, didn't work as simple as that, but this did:

"release:sample:major": "git-branch-is sample && standard-version --skip.changelog --skip.commit --skip.tag --release-as major && standard-version --no-verify --skip.changelog --skip.tag --prerelease sample --release-as major",
"release:sample:minor": "git-branch-is sample && standard-version --skip.changelog --skip.commit --skip.tag --release-as minor && standard-version --no-verify --skip.changelog --skip.tag --prerelease sample --release-as minor",
"release:sample:patch": "git-branch-is sample && standard-version --skip.changelog --skip.commit --skip.tag --release-as patch && standard-version --no-verify --skip.changelog --skip.tag --prerelease sample --release-as patch"

It's a bit complex and verbose but it does the trick for now. I wish there was something simpler like npm version above though...

well.. first, congrats for the solution/workaround ;-)

In fact, the first solution I've mentioned is "state-of-the-art", as described in the conventional commit specification (see # 3 in the spec summary):

BREAKING CHANGE: a commit that has a footer BREAKING CHANGE:, or appends a ! after the type/scope, introduces a breaking API change (correlating with MAJOR in semantic versioning). A BREAKING CHANGE can be part of commits of any type.

Note: you can use a footnote with BREAKING CHANGE or use a "!" sign like in feat(hotdog)!: ...

In fact (in context of "conventional commit"):
a major version should not be bumped until it is REALLY IMPORTANT e.g. when there's a breaking change ;) As a rule of thumb: "no major bump until big changes".
Hence, adding a feature of fixing a bug is not enough to bump on major.
If your company do not like to adopt this restriction i.e. need to be "very flexible", that's fine too!
In this case, it should not stick to the conventional versioning, since the tools supporting this spec won't solve all the company's use cases.

In fact (in context of "conventional commit"):
a major version should not be bumped until it is REALLY IMPORTANT e.g. when there's a breaking change ;) As a rule of thumb: "no major bump until big changes".
Hence, adding a feature of fixing a bug is not enough to bump on major.
If your company do not like to adopt this restriction i.e. need to be "very flexible", that's fine too!
In this case, it should not stick to the conventional versioning, since the tools supporting this spec won't solve all the company's use cases.

I'm well aware of all that but this is a very specific use case.