Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[BUG] Filter version with prerelease tags #357

Closed
marceloavf opened this issue Dec 21, 2020 · 5 comments · Fixed by #671
Closed

[BUG] Filter version with prerelease tags #357

marceloavf opened this issue Dec 21, 2020 · 5 comments · Fixed by #671
Labels
Bug thing that needs fixing

Comments

@marceloavf
Copy link

What / Why

I'm trying to extract a version from string keeping prerelease tags but it's not considering it.

How

Current Behavior

For example, running this code bellow, it should tell me that it's prerelease with a preview tag or just keep its integrity

var semver = require("semver");
semver.coerce('installer-v1.66.18-preview.6', { includePrerelease: true, loose: true });

But it returns:

build: []
includePrerelease: true
loose: true
major: 1
minor: 66
options: Object {includePrerelease: true, loose: true}
patch: 18
prerelease: []
raw: "1.66.18"
version: "1.66.18"
SemVer Prototype

Expected Behavior

I do expect it to keep version like 1.66.18-preview.6 or at least tell me that it's a prerelease instead of getting rid of everything.

notlee added a commit to Financial-Times/origami-ci-tools that referenced this issue Feb 3, 2021
Previously this did not work as expected as `semver.coerce` does not
appear to handle prerelease versions. Relates to:
npm/node-semver#357

Instead we can use `semver.prerelease` for our purposes.

We should improve test coverage here but I suspect this action
may disappear in the near future (either with a move to a mono
repo, or by extracting the bundle size notice and using a similar
approach to services for publishing).
notlee added a commit to Financial-Times/origami-ci-tools that referenced this issue Feb 3, 2021
Previously this did not work as expected as `semver.coerce` does not
appear to handle prerelease versions. Relates to:
npm/node-semver#357

Instead we can use `semver.prerelease` for our purposes.

We should improve test coverage here but I suspect this action
may disappear in the near future (either with a move to a mono
repo, or by extracting the bundle size notice and using a similar
approach to services for publishing).
JakeChampion pushed a commit to Financial-Times/origami-ci-tools that referenced this issue Feb 15, 2021
Previously this did not work as expected as `semver.coerce` does not
appear to handle prerelease versions. Relates to:
npm/node-semver#357

Instead we can use `semver.prerelease` for our purposes.

We should improve test coverage here but I suspect this action
may disappear in the near future (either with a move to a mono
repo, or by extracting the bundle size notice and using a similar
approach to services for publishing).
JakeChampion pushed a commit to Financial-Times/origami-ci-tools that referenced this issue Feb 15, 2021
Previously this did not work as expected as `semver.coerce` does not
appear to handle prerelease versions. Relates to:
npm/node-semver#357

Instead we can use `semver.prerelease` for our purposes.

We should improve test coverage here but I suspect this action
may disappear in the near future (either with a move to a mono
repo, or by extracting the bundle size notice and using a similar
approach to services for publishing).
@tjenkinson
Copy link
Contributor

Just discovered the same issue via https://github.com/release-drafter/release-drafter

@tjenkinson
Copy link
Contributor

tjenkinson commented Aug 9, 2021

Looks like we should try semver.parse first, and then semver.coerce if parse returns null

@aschempp
Copy link

aschempp commented Aug 10, 2021

@flleeppyy
Copy link

bump

@alasdairhurst
Copy link

I'd imagine that even without providing any options - includePrerelease (since it's not a range), or loose (since it's 100% valid semver), the prerelease part of the version should be persisted.

The documentation does go over the algorithm used, and does only mention an example of (1, 1.2, 1.2.3), but it's not clear that the example is exclusive. At the very least the docs could be updated to explicitly say that other valid server tokens aside from x.y.z, such as prerelease identifiers are not persisted after coersion to avoid confusion.

I presume any fix would be a breaking change on the package since I can imagine people could be relying on the outcome to have no prerelease identifier?

wraithgar added a commit that referenced this issue Jan 31, 2024
# What / Why

Introduces the new coerce option `includePrerelease`, if set, allowing
to preserve pre-release and build parts of a version.

## References

Fixes #592
Fixes #357

---------

Co-authored-by: madtisa <temp-email-for-oauth-madtisa@gitlab.localhost>
Co-authored-by: Gar <wraithgar@github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug thing that needs fixing
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants