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

Support NPM verison ">=" following by a whitespace #127

Open
larytet opened this issue Jan 21, 2022 · 9 comments
Open

Support NPM verison ">=" following by a whitespace #127

larytet opened this issue Jan 21, 2022 · 9 comments
Labels
Status:DiscussionNeeded Topic:NPM Implementing NPM-style version specifiers Type:Enhancement

Comments

@larytet
Copy link

larytet commented Jan 21, 2022

For example >= 1.4.0 < 2
Apparently there are ~30K packages in the NPM which dependencies lists have versions with a white space.

Also support for latest

I see also (illegal?) ~2.2.0rc
More outlandish examples:
^v2.7.4, > =3.10, ~>1.4.1, ~ 2.0.0, ^0.20.0 && >=0.20.0, ^00.5.1
In the package @ansyn/core 0.2.82.4

@rbarrois
Copy link
Owner

rbarrois commented Feb 6, 2022

Hey! That's an interesting suggestion; however, the specification at https://github.com/npm/node-semver#range-grammar does not allow that form:

primitive  ::= ( '<' | '>' | '>=' | '<=' | '=' ) partial
partial    ::= xr ( '.' xr ( '.' xr qualifier ? )? )?
xr         ::= 'x' | 'X' | '*' | nr
nr         ::= '0' | ['1'-'9'] ( ['0'-'9'] ) *

Would you have any pointer to the semver docs explaining how those invalid forms are to be handled?
Otherwise, this could be implemented as a .coerce() form, or a lax=True / strict=False option to the NpmSpec constructor...

@rbarrois rbarrois added Status:DiscussionNeeded Topic:NPM Implementing NPM-style version specifiers Type:Enhancement labels Feb 6, 2022
@rbarrois
Copy link
Owner

rbarrois commented Feb 6, 2022

Also, please note that this is the same topic as discussed in #115 and in node-semver at npm/node-semver#392

@pombredanne
Copy link
Contributor

@rbarrois

Would you have any pointer to the semver docs explaining how those invalid forms are to be handled?
Otherwise, this could be implemented as a .coerce() form, or a lax=True / strict=False option to the NpmSpec constructor...

My preference would be to accept that node-semver documented specs are incomplete and that the only correct spec is the JS code? What do you think?

@larytet
Copy link
Author

larytet commented May 18, 2022

I have a workaround. I clean the versions where I can, ignore version in some cases. 100% accuracy (accuracy is defined by interoperability with NPM install) is not critical in my use case.

@pombredanne
Copy link
Contributor

@larytet re:

I have a workaround. I clean the versions where I can, ignore version in some cases. 100% accuracy (accuracy is defined by interoperability with NPM install) is not critical in my use case.

Thanks! this helps.

I guess we will need this in https://github.com/nexB/univers/blob/6ad300ea515f99ffaae8b6a160724c32f027b5c0/src/univers/version_range.py#L226 for correctness so @larytet is there some code we can stole from you for this? 😇

@TG1999 @sbs2001 @Hritik14 FYI

@larytet
Copy link
Author

larytet commented May 18, 2022

This is a proprietary code. There is not anything complex. I remove whitespaces, I apply a few simple regex. Please keep in mind that there is less ~3% packages (if my memory serves) with non complying versions. I left the project and I can't check it now.
I think that after a few iterations I have ended up with "translation" of NPM version to Maven version, and using maven class for all versions.

@eranbrodet

@SpecialK118
Copy link

SpecialK118 commented Dec 13, 2023

Any news regarding this ticket?
I've encountered the same error when trying to parse jquery dependency jquery-ui version in jquery-ui/package.json file (with and without the whitespace):

"dependencies": {
	"jquery": ">=1.8.0 <4.0.0"
},
  >>> Spec(">=1.8.0 <4.0.0")
  Traceback (most recent call last):
    File "<stdin>", line 1, in <module>
    File "/Users/ktal/git/infinimetrics/.venv/lib/python3.8/site-packages/semantic_version/base.py", line 1196, in __init__
      super(LegacySpec, self).__init__(expression)
    File "/Users/ktal/git/infinimetrics/.venv/lib/python3.8/site-packages/semantic_version/base.py", line 618, in __init__
      self.clause = self._parse_to_clause(expression)
    File "/Users/ktal/git/infinimetrics/.venv/lib/python3.8/site-packages/semantic_version/base.py", line 1014, in _parse_to_clause
      return cls.Parser.parse(expression)
    File "/Users/ktal/git/infinimetrics/.venv/lib/python3.8/site-packages/semantic_version/base.py", line 1034, in parse
      raise ValueError("Invalid simple block %r" % block)
  ValueError: Invalid simple block '>=1.8.0 <4.0.0'

>>> Spec(">=1.8.0<4.0.0")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Users/ktal/git/infinimetrics/.venv/lib/python3.8/site-packages/semantic_version/base.py", line 1196, in __init__
    super(LegacySpec, self).__init__(expression)
  File "/Users/ktal/git/infinimetrics/.venv/lib/python3.8/site-packages/semantic_version/base.py", line 618, in __init__
    self.clause = self._parse_to_clause(expression)
  File "/Users/ktal/git/infinimetrics/.venv/lib/python3.8/site-packages/semantic_version/base.py", line 1014, in _parse_to_clause
    return cls.Parser.parse(expression)
  File "/Users/ktal/git/infinimetrics/.venv/lib/python3.8/site-packages/semantic_version/base.py", line 1034, in parse
    raise ValueError("Invalid simple block %r" % block)
ValueError: Invalid simple block '>=1.8.0<4.0.0'

@rbarrois
Copy link
Owner

@SpecialK118 The upstream discussion in npm/node-semver#392 hasn't had any movement.

I would like to decide this based on an explicit documented behaviour on NPM end, but couldn't find any.
Could you help me with finding such a guideline, or official example stating that this behaviour is supposed to be accepted (and not just accidentally supported by the implementation)?

@SpecialK118
Copy link

@rbarrois
It looks like I can workaround this issue by using NpmSpec instead of Spec, which is able to parse this format.

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 Type:Enhancement
Projects
None yet
Development

No branches or pull requests

4 participants