Skip to content
This repository has been archived by the owner on Aug 11, 2022. It is now read-only.

Make default --save semver option configurable #4713

Closed
timoxley opened this issue Feb 18, 2014 · 8 comments
Closed

Make default --save semver option configurable #4713

timoxley opened this issue Feb 18, 2014 · 8 comments

Comments

@timoxley
Copy link
Contributor

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:

$ npm config set semver-range=close # set default to use 'close' range 
$ npm install --save [--range=^ | --range=compat[ible]] express # use ^
$ npm install --save [--range=~ | --range=close | --close] express # use ~
$ npm install --save [--no-range | --range=false] express # use exact version

or perhaps the range keyword is semver:

$ npm install --save [--semver=^ | --semver=compat[ible]] express # use ^
$ npm install --save [--semver=~ | --semver=close | --close] express # use ~
$ npm install --save [--no-semver | --semver=false] express # use exact version

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:

{
 "name": "express",
 "preferredSemver": "^", // patch and minors probably safe
}
{
 "name": "mux-demux",
 "preferredSemver": "~", // I follow strict semver
}
{
 "name": "underscore",
 "preferredSemver": "@" // no semver, please use fixed versions
}
{
 "name": "polyfill-webcomponents",
 "preferredSemver": "*" // yolo
}
@timoxley
Copy link
Contributor Author

Inspired by #4587

@timoxley
Copy link
Contributor Author

cc @balupton

@balupton
Copy link

+1. Although for me, I'd just be happy with a revert of #4587

@domenic
Copy link
Contributor

domenic commented Feb 18, 2014

-1.

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.

This is a good thing. If you want npm's conveniences, you have to buy into npm's paradigm.

@isaacs
Copy link
Contributor

isaacs commented Feb 18, 2014

Also -1.

--save is designed to take advantage of the common usage of SemVer versions. Looking at how most packages manage their versions, ^ is almost always the ideal choice. Nudging people towards using ^ will make us all more consistent in how we version our stuff, which is the explicit goal of SemVer.

~ is borrowed from rubygems. It dates from a time before common acceptance of SemVer paradigms, and is routinely confusing to people. Making it not confusing (ie, making it do what ^ does) makes people confused who are familiar with how it works in rubygems. It is problematic, and we should not be encouraging its use.

I do not want to add multiple different configurable ways to do this. However, I would be ok with adding a single --save-exact | -E boolean option, which causes it to always save the exact version number installed. Patch welcome for that.

@timoxley
Copy link
Contributor Author

Points noted. Thanks for elaborating @isaacs

@balupton
Copy link

How does something like this get the attention of @domenic and @isaacs but missing packages of #4596 don't?

@isaacs
Copy link
Contributor

isaacs commented Feb 20, 2014

@balupton Well, about a dozen people (including you) pinged me personally on twitter about this issue, and one person IM'ed me directly asking for a response. I'll dig into #4596 today.

timoxley added a commit to timoxley/npm that referenced this issue Feb 20, 2014
rlidwka added a commit to rlidwka/yapm that referenced this issue Mar 4, 2014
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)
rlidwka added a commit to rlidwka/yapm that referenced this issue Mar 4, 2014
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)
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants