Skip to content

fix: split dotted prerelease identifiers in inc()#883

Open
MerlijnW70 wants to merge 1 commit into
npm:mainfrom
MerlijnW70:fix/inc-prerelease-dotted-identifier
Open

fix: split dotted prerelease identifiers in inc()#883
MerlijnW70 wants to merge 1 commit into
npm:mainfrom
MerlijnW70:fix/inc-prerelease-dotted-identifier

Conversation

@MerlijnW70

Copy link
Copy Markdown

Summary

SemVer.prototype.inc('prerelease', identifier) stores the identifier as a single element of the prerelease array even when it contains dots. A dotted identifier such as 'x.y' is stored as ['x.y', 0] instead of ['x', 'y', 0]. The formatted version string is correct, but the in-memory prerelease array is malformed, so comparePre() compares a dotted element against a plain identifier and mis-orders versions.

Reproduction

const { SemVer } = require('semver')
const semver = require('semver')

const a = new SemVer('1.2.3-alpha').inc('prerelease', 'x.y')
a.version            // '1.2.3-x.y.0'   (correct)
a.prerelease         // ['x.y', 0]      <-- should be ['x', 'y', 0]

a.compare(new SemVer('1.2.3-x.y.1'))          //  1   (claims x.y.0 > x.y.1)
semver.compare('1.2.3-x.y.0', '1.2.3-x.y.1')  // -1   (correct)

The same version compared as a SemVer object versus as its string yields opposite results. Because comparePre() walks the array element-by-element, the malformed 'x.y' element is compared with compareIdentifiers('x.y', 'x') and wins lexically, so 1.2.3-x.y.0 is reported as greater than 1.2.3-x.y.1.

Root cause

In classes/semver.js, the pre case of inc() assigns the raw identifier straight into the array:

let prerelease = [identifier, base]   // identifier may be 'x.y'
if (identifierBase === false) {
  prerelease = [identifier]
}

The surrounding code already knows identifiers can be dotted — a few lines down it uses identifier.split('.').length — but the assignment itself never splits. Every other consumer (comparePre, and the constructor) assumes one dot-free identifier per array element.

Fix

Split the identifier on . and numberify numeric ids, exactly as the SemVer constructor does when parsing prerelease identifiers, so comparePre() sees one identifier per element:

const identifiers = identifier.split('.').map((id) => {
  if (/^[0-9]+$/.test(id)) {
    const num = +id
    if (num >= 0 && num < MAX_SAFE_INTEGER) {
      return num
    }
  }
  return id
})
let prerelease = [...identifiers, base]
if (identifierBase === false) {
  prerelease = identifiers
}

After the fix, inc('1.2.3','prerelease','1.2').prerelease deep-equals parse('1.2.4-1.2.0').prerelease ([1, 2, 0]), and object comparison agrees with string comparison. Non-dotted identifiers ('beta', 'dev', …) are unaffected.

Tests

  • Adds a dedicated regression test in test/functions/inc.js asserting the prerelease array shape and that object comparison matches string comparison (the fixture suite only checks the version string, which is why this went unnoticed).
  • Adds fixture cases in test/fixtures/increments.js for dotted identifiers, including a numeric id and a numeric id ≥ 2^53 (kept as a string, matching the constructor).

Full suite passes with 100% coverage and lint clean.

SemVer.prototype.inc('prerelease', identifier) stored the identifier as a
single element of the prerelease array, even when it contained dots, so a
dotted identifier such as 'x.y' was stored as ['x.y', 0] instead of
['x', 'y', 0]. The version string was still formatted correctly, but the
in-memory prerelease array was malformed, so comparePre() compared a
dotted element against a plain one and mis-ordered versions:

    const a = new SemVer('1.2.3-alpha').inc('prerelease', 'x.y')
    a.compare(new SemVer('1.2.3-x.y.1'))          //  1  (x.y.0 > x.y.1?!)
    semver.compare('1.2.3-x.y.0', '1.2.3-x.y.1')  // -1

The same version compared as an object versus as its string produced
opposite results.

Split the identifier on '.' and numberify numeric ids, matching how the
SemVer constructor parses prerelease identifiers, so comparePre() sees
exactly one identifier per array element.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant