You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[QUESTION/FEATURE] Usage of commas inside constraints. #468
We are using a JS app to parse PHP composer.json files and wish to use this library to compare a version number with that constraint.
Currently: What is considered a valid constraint for composer >=5.6,<=8.1.99 will not parse with this library.
The Hopeful Ideal: That we can use this library to parse this constraint with the , being considered the same as a .
For background, there is an issue that pertains to this, however I will try to lay out the argument here.
I tried to lookup whether the semver specification says anything regarding specifying version ranges but came up empty handed. As I understand it PHP's composer may not be the only library which parses a version range constraint in this way, some examples:
I'm sure there are more, so my request is if either, a comma could be considered a valid alternative to a space within this package, or if the .coerce() or .clean() methods could be modified for use in these instances? Or maybe there already exists a way and this is all for naught. Thanks for considering this either way.
@ljharb I think you're talking about changing the official npm specification. I'm asking if this package can support semver ranges as currently implemented outside of npm so we can use it parse values from other semver compliant package managers.
Since that would no doubt have the side effect of what would be allowed within package.json, the fallback request is whether this package could clean/coerce these non-npm-valid ranges into npm-valid ones. The 3 package manager formats listed in this issue were just the first 3 I checked (add in PHP and that's 4).
Assuming that semver were to add ranges to their specification, I would also find it unlikely that they would reject the use of a comma when it already has widespread use.
Activity
[-][QUESTION] Usage of commas inside constraints.[/-][+][QUESTION/FEATURE] Usage of commas inside constraints.[/+]ljharb commentedon Aug 11, 2022
It doesn’t yet, but when it does it’ll be like npm does it - spaces, not commas.
boesing commentedon Aug 12, 2022
The question would be: why not supporting commas if it is at least supported by other semver parsers in 3 different languages?
PHPs
composer/semverimplementation does support it as well:https://getcomposer.org/doc/articles/versions.md#version-range
ljharb commentedon Aug 12, 2022
Because adding that complexity isn't particularly valuable - there's one way to do it; we don't need two.
internalsystemerror commentedon Aug 12, 2022
@ljharb I think you're talking about changing the official npm specification. I'm asking if this package can support semver ranges as currently implemented outside of npm so we can use it parse values from other semver compliant package managers.
Since that would no doubt have the side effect of what would be allowed within package.json, the fallback request is whether this package could clean/coerce these non-npm-valid ranges into npm-valid ones. The 3 package manager formats listed in this issue were just the first 3 I checked (add in PHP and that's 4).
Assuming that semver were to add ranges to their specification, I would also find it unlikely that they would reject the use of a comma when it already has widespread use.
ljharb commentedon Aug 12, 2022
This package is exclusively for npm. You could comment on the ranges PR on the semver spec about it tho, I'm sure
internalsystemerror commentedon Aug 12, 2022
It's a published publicly available package so you'll forgive my assumption then.
I wasn't aware there was one, but thanks for the heads up!
(Edit: linking the PR for reference semver/semver#584)