Repository navigation
[FEATURE] Allow satisfies to throw errors #418
Description
What / Why
It would be nice to have
satisfiesthrow an error so that we may see that the range does not satisfy due to an invalid range as opposed to an invalid version. The range error that we'd like to see is here:Line 41 in cb1ca1d
When
- When verifying engine versions during
npm install - When adding a dependency to package.json during
npm install
Where
- npm/node-semver
How
Current Behavior
Create an empty project with the following package.json:
{
"name": "foo",
"version": "1.0.0",
"description": "",
"main": "index.js",
"scripts": {
"test": "echo \"Error: no test specified\" && exit 1"
},
"author": "",
"license": "ISC",
"engines": {
"node": ">=6.5.0 !15"
},
"engineStrict": true
}Run npm install and you get:
npm WARN EBADENGINE Unsupported engine {
npm WARN EBADENGINE package: 'foo@1.0.0',
npm WARN EBADENGINE required: { node: '>=6.5.0 !15' },
npm WARN EBADENGINE current: { node: 'v16.11.1', npm: '8.0.0' }
npm WARN EBADENGINE }
up to date, audited 1 package in 414ms
found 0 vulnerabilities
Expected Behavior
Create an empty project with the following package.json:
{
"name": "foo",
"version": "1.0.0",
"description": "",
"main": "index.js",
"scripts": {
"test": "echo \"Error: no test specified\" && exit 1"
},
"author": "",
"license": "ISC",
"engines": {
"node": ">=6.5.0 !15"
},
"engineStrict": true
}Run npm install and ideally get something like:
npm WARN EBADENGINE Invalid SemVer Range: >=6.5.0 !15
up to date, audited 1 package in 414ms
found 0 vulnerabilities
Who
- n/a
References
- n/a
Reacted by Alan Slater and Jeff Walker
Activity
lukekarrys commentedon Apr 10, 2022
I'm not opposed to this but I do think this would be a breaking change.
AlanSl commentedon Jun 16, 2022
This would also be very useful for debugging when a bug or failure in semver is encountered, such as #381 or #354
Currently, many errors or failures within semver return a false negative with no clue that something has failed - unless a debugger with "break on caught errors" is active, they appear exactly like a completed validation that has successfully judged the version to be invalid.
If what actually happened was semver hit an error mid-validation due to some bundling issue or internal bug, it's important to be able to see that and treat it differently, rather than have an operation continue based on possibly incorrect information.
(we've just had exactly this happen, and it took a long time to figure out that there was a caught internal error in semver caused by a bundling issue)