-
Notifications
You must be signed in to change notification settings - Fork 3k
Make default --save semver option configurable #4713
Comments
Inspired by #4587 |
cc @balupton |
+1. Although for me, I'd just be happy with a revert of #4587 |
-1.
This is a good thing. If you want npm's conveniences, you have to buy into npm's paradigm. |
Also -1.
I do not want to add multiple different configurable ways to do this. However, I would be ok with adding a single |
Points noted. Thanks for elaborating @isaacs |
Implementing suggestion in npm/npm#4713 You can return old npm behaviour in config: yapm config set save-range '~' yapm install --save express Or just use range shortcut in the command line: yapm install --save --range='~' express Available options for save-range are: - "~" - "^" - ">=" - "<=" - "=" - no range (exact)
Implementing suggestion in npm/npm#4713 You can return old npm behaviour in config: yapm config set save-range '~' yapm install --save express Or just use range shortcut in the command line: yapm install --save --range='~' express Available options for save-range are: - "~" - "^" - ">=" - "<=" - "=" - no range (exact)
Allowing the default semver range to to be configurable and passed on the command line will probably get more developers making a conscious choice about their semver ranges on a per-package basis.
Currently, it seems if you don't want to use the default semver, you're effectively punished by npm as you can no longer use any of the --save conveniences that it provides.
Most will pick the default semver range and not give it another thought simply because it's convenient. Maybe that's a good thing though, as ~ is probably better than everyone getting paranoid and using fixed ranges all the time.
Perhaps the issue of whether to use
~
or^
is solved simply by making it configurable globally and at --save time?Something like:
or perhaps the
range
keyword issemver
:Perhaps packages themselves could indicate how strict they are about semver. i.e. When npm installs a package with
--save
, it will use the package's 'preferred semver' if the user has not overridden it. Ideally, everyone follows semver strictly but as there's no real way to enforce semver, this doesn't really happen in reality.e.g. specifying preferred semver via package.json:
The text was updated successfully, but these errors were encountered: