hapijs / somever Goto Github PK

Support plan

• which support plan is this issue covered by? (e.g. Community, Core, Plus, or Enterprise): Enterprise, I think
• is this issue currently blocking your project? (yes/no): not really - there's always semver and there's always Somever.version(x).compare(y)
• is this issue affecting a production system? (yes/no): no

Context

• node version: v10.16.3
• module version: latest
• environment (e.g. node, browser, native): node
• used with (e.g. hapi application, another framework, standalone, ...): standalone
• any other relevant information:

What problem are you trying to solve?

I'd really like to be able to sort((a, b) => Somever.compare(a, b)).

Do you have a new or modified API suggestion to solve the problem?

Expose the existing static internals.Version.compare as public.

🚨 You need to enable Continuous Integration on Greenkeeper branches of this repository. 🚨

To enable Greenkeeper, you need to make sure that a commit status is reported on all branches. This is required by Greenkeeper because it uses your CI build statuses to figure out when to notify you about breaking changes.

Since we didn’t receive a CI status on the greenkeeper/initial branch, it’s possible that you don’t have CI set up yet.
We recommend using:

• CircleCI
• Travis CI
• Buildkite
• CodeShip
• Azure Pipelines
• TeamCity
• Buddy
• AppVeyor
  But Greenkeeper will work with every other CI service as well.

If you have already set up a CI for this repository, you might need to check how it’s configured. Make sure it is set to run on all new branches. If you don’t want it to run on absolutely every branch, you can whitelist branches starting with greenkeeper/.

Once you have installed and configured CI on this repository correctly, you’ll need to re-trigger Greenkeeper’s initial pull request. To do this, please click the 'fix repo' button on account.greenkeeper.io.

Support plan

• is this issue currently blocking your project? (yes/no): no
• is this issue affecting a production system? (yes/no): yes

Context

• node version: v16.4.0-pre
• module version with issue: hapi v20.1.4
• last module version without issue: Not sure
• environment (e.g. node, browser, native): Node
• used with (e.g. hapi application, another framework, standalone, ...): Node.js Platform Test Suite
• any other relevant information: N/A

What are you trying to achieve or the steps to reproduce?

When the Node.js release team tests prereleases for Node.js releases, we run the hapi test suite (configured here: https://github.com/nodejs/citgm/blob/main/lib/lookup.json#L2-L5) as part of tests on the Node.js ecosystem. One of the tests fails consistently due to what looks like a bug with how Somever.match() parses the format of the version.

In this test: https://github.com/hapijs/hapi/blob/master/test/server.js#L2793-L2805, the test will fail on prereleases with the format of something like v16.4.0-pre. process.version will always return vx.y.z, and the tests do a lot of testing for prerelease syntax, so this looks like a bug.

What was the result you got?

Failed tests:
   753) Server register() validates node version:
       Expected [Promise] to not reject with an error but got [Error: Plugin test requires node version >=8.x.x but found v16.4.0-pre]

What result did you expect?

I expected .match() to recognize that v16.4.0-pre is within the range of >=8.x.x.