Question
Context
Currently, when using semverGroups with "range": "^", syncpack always produces the full ^x.y.z format (e.g. ^1.0.0).
Node-semver also considers ^1 and ^1.2 as valid caret ranges — they're semantically equivalent to ^1.0.0 and ^1.2.0 respectively, but some teams prefer the shorter forms.
Request
Would it be possible to support a range value like "^.x" or similar that formats versions as caret + major only?
For example:
Current ("range": "^") |
Requested |
^1.0.0 |
^1 |
^2.0.0 |
^2 |
Use case
For internal monorepo packages where the intent is "any compatible version within this major", the shorter ^1 form communicates that intent more directly, it says "I don't care about a specific minor or patch floor, just keep me on major 1". The full ^1.0.0 can imply a deliberate choice of 1.0.0 as the minimum, when in practice the consumer just wants major-level compatibility.
I'd love your take on whether this is even a good idea.
Code of Conduct
Question
Context
Currently, when using
semverGroupswith"range": "^", syncpack always produces the full^x.y.zformat (e.g.^1.0.0).Node-semver also considers
^1and^1.2as valid caret ranges — they're semantically equivalent to^1.0.0and^1.2.0respectively, but some teams prefer the shorter forms.Request
Would it be possible to support a range value like
"^.x"or similar that formats versions as caret + major only?For example:
"range": "^")^1.0.0^1^2.0.0^2Use case
For internal monorepo packages where the intent is "any compatible version within this major", the shorter
^1form communicates that intent more directly, it says "I don't care about a specific minor or patch floor, just keep me on major 1". The full^1.0.0can imply a deliberate choice of1.0.0as the minimum, when in practice the consumer just wants major-level compatibility.I'd love your take on whether this is even a good idea.
Code of Conduct