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

Incomplete support for NpmSpec, according to node-semver #115

Open
gnattishness opened this issue Jul 10, 2021 · 4 comments · May be fixed by #116
Open

Incomplete support for NpmSpec, according to node-semver #115

gnattishness opened this issue Jul 10, 2021 · 4 comments · May be fixed by #116
Labels
Status:DiscussionNeeded Topic:NPM Implementing NPM-style version specifiers

Comments

@gnattishness
Copy link

python-semanticversion currently appears to support "canonical" NPM version specs, as according to their range.bnf, but the node-semver implementation also accepts a superset of that syntax as valid.
For example, the implementation allows spaces between the prefix and the version (> 1.2.3), or additional whitespace within a hyphen-range (0.1.2 - 3.4.5).
It also has a ~> prefix, which appears to be equivalent to ~.

The NpmSpec does not accept these as valid, and raises a ValueError.

I believe that NpmSpec should aim to be equivalent to the node-semver implementation, correctly parsing anything NPM accepts as valid.

Note also the related issue npm/node-semver#392, which goes into more detail about the discrepancy between the syntax definition and the implementation.

@gnattishness
Copy link
Author

(Note: this extra syntax is all accepted as valid by npm even in strict parsing mode ("loose": false))

@gnattishness gnattishness linked a pull request Jul 10, 2021 that will close this issue
@rbarrois
Copy link
Owner

Thanks for the bug report, and the investigation!

I'd like to wait until one position is taken on npm/node-semver#392 to adjust here accordingly.

@pombredanne
Copy link
Contributor

My 2 cents: accepting more and matching node-semver's code with winks, quirks, features and bugs would be my preferred approach

@gnattishness
Copy link
Author

@pombredanne This approach would resolve the downstream bug I encountered (where the project accepts "npm style" versions, and the python implementation will sometimes reject version strings that are accepted elsewhere)
This would be similarly encountered by a python project that's needing to parse npm package.lock files.

But I appreciate trying to match some "reference implementation" is often much more troublesome than a well-defined spec, particularly if it's not communicated clearly whether those quirks are internal implementation details or not.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Status:DiscussionNeeded Topic:NPM Implementing NPM-style version specifiers
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants