[BUG] Filter version with prerelease tags

[marceloavf]

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.

[tjenkinson]

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

[tjenkinson]

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

[aschempp]

@tjenkinson you might consider using semver.valid like this:

https://github.com/contao/contao-manager/blob/8d86a863d585d5d202c9dec85cb29d977f896ab9/src/store/packages.js#L195-L199

[flleeppyy]

bump

[alasdairhurst]

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?