Create 0002-no-caret-prerelease-installs.md #14

hzoo · 2018-07-06T20:17:43Z

Mentioned this to @zkat last month so figured I'd write something at least, (probably want the same in yarn actually if it lands)!

Rendered: https://github.com/hzoo/rfcs-1/blob/patch-2/0002-no-caret-prerelease-installs.md

Example gissues related to this:

On update to version 7.00-beta.46 Get Decorators Support Error [BUG] babel/babel#7786 (comment)
npm run serve error: You must pass the "decoratorsLegacy": true option to @babel/preset-stage-2 vuejs/vue-cli#1162 (another issue is also with integrations that may use prerelease versions with ^ but that might be a different issue)
https://medium.com/@mbostock/prereleases-and-npm-e778fc5e2420
https://twitter.com/left_pad/status/980545530559418369

There is a lot of confusion with prereleases in general (both from the package author and user side), so this doesn't prevent anyone from using ^ but it at least prevents people from accidentally adding it ^ given the default.

Might even suggest people get warned of keeping the ^ somehow but maybe that's too much.

zkat

I appreciate this RFC. I think prerelease versions have historically been a huge footgun and this seems to be a direction to go if we want to make it hurt a little less. I'm unclear about how it would interact with other parts of the system, what the escape hatches are, if any, and why you think this wouldn't be better served by a change in how semver specifies these, since that's ultimately the source of this pain. (Not that I think modifying semver is a better solution but I think exploring that idea and including the conclusion in this RFC would help immensely with context)

zkat · 2018-07-06T20:25:35Z

0002-no-caret-prerelease-installs.md

+
+## Detailed Explanation
+
+`npm install`, when writing to `package.json` (like with `--save` or `--save-dev`), should check with semver and only add the `^` if the version isn't a prerelease. I don't believe it should affect anything else.


How do users opt into using ranges for prerelease, if they'd like to? This feature is currently controlled by the --save-prefix config, and this RFC makes no mention of how these changes will interact with that option.

Sorry, I didn't know about that option, wasn't really sure what to put for this section actually!

iarna · 2018-07-06T20:30:24Z

As a consumer I would be quite surprised if you included breaking changes in a pre-release that wasn't a major version above the current non-prerelease? But you're right, nothing says in that case that you'd be wrong to break from pre-release to pre-release…

Something I'd like to figure out for this:

How many packages have pre-release range specifiers currently matching multiple versions? How many projects are expecting the current behavior?

hzoo · 2018-07-06T21:17:58Z

TBH, I would be quite surprised if you included breaking changes in a pre-release that wasn't a major version above the current non-prerelease?

Yeah this is mostly in the case of Babel right now where the current latest is 6.x.

We are publishing 7.x as alpha, beta, etc and aren't done making breaking changes (not all of them are intentional but there are definitely some) but yet it doesn't stop anyone from trying to use it in their projects.

How many packages have pre-release range specifiers currently matching multiple versions? How many projects are expecting the current behavior?

Yeah, that's a good question! I think people would like it since you don't have to continually update but that assumes the non-breaking in-between pre-releases. I think many projects use pre-release as an opportunity to do breaking changes though.

Or hmm that's interesting! Maybe specifically for a new major release (so only for a 7.0.0-beta.1 vs. 7.1.0-beta.2)? So not sure if tying it specifically like that would be better then? For a major version, you might plan breaking changes in between while for a minor bump with a beta you might just want to wait a period for regressions?

Although I realize it's probably that we aren't using semver correctly and each breaking change should be a move from beta.1 to cxxx.0 instead of beta.1 to beta.2? I don't find a lot of projects doing this though, and there is some confusion there.

ljharb · 2018-07-07T00:11:11Z

fwiw i do generally find it surprising when the prerelease line (alpha/beta/etc) has breaking changes inside the same line.

hzoo · 2018-07-07T13:55:55Z

Yeah, I guess this is specifically for when doing a major bump and you just want to get some testing out there but clearly not stable yet. I think it's pretty common for breaking changes in alpha/beta, and sometimes RC for some projects.

Like see RxJS, others? I guess I don't see how a package author would do it otherwise if they are releasing and landing different kinds of changes before doing the final release?

Edit: looks like ^ with alpha also matches beta, rc as well so it would auto download it too.

iarna

After some discussion @zkat and I are ok with this. This RFC will need an implementation section to land. I believe the implementation will be just the addition of another conditional to https://github.com/npm/cli/blob/latest/lib/install/deps.js#L303

Please note that the implementation section does not need an actual implementation, just a discussion of how it would be done.

trusktr · 2018-08-08T20:20:46Z

Something interesting might be something similar to semver after the beta:

7.0.0-beta.1.0
7.0.0-beta.1.1
7.0.0-beta.1.2
7.0.0-beta.2.0 <-- breaking change
7.0.0-beta.2.1

zkat · 2018-12-20T22:03:57Z

@hzoo hey Henry, just a heads-up that this is ready to land, but we need a small implementation section in order to ratify it. Let us know when that happens! Thanks for your time and patience :)

hzoo · 2018-12-21T00:27:10Z

Oops never got around to doing it, should of been easy since @iarna already pointed it out!! Ok something like that @zkat? Thanks for the ping too

everything's been ratified!

zkat

Thanks for adding the implementation section, @hzoo! The team just met and decided we're ready to ratify this. Thanks again for sending this RFC our way and I hope the implementation makes you and yours lives easier! 🎉

…se-installs.md

SimenB · 2019-01-10T23:52:03Z

0008-no-caret-prerelease-installs.md

+```diff
+"devDependencies": {
+-   "@babel/register": "^7.0.0-beta.52"
+   "@babel/register": "7.0.0-beta.52"


a bit odd that it says @babel/register here when it's @babel/core in the install command above 😅

lol good point, feel free to PR or I can later

Can do, simple enough. Just wasn't sure if it was worth a PR

EDIT: #31

hzoo and others added 2 commits July 6, 2018 16:13

Create 0002-no-caret-prerelease-installs.md

0c12064

Update 0002-no-caret-prerelease-installs.md

c1fc258

zkat reviewed Jul 6, 2018

View reviewed changes

zkat added :under-discussion labels Jul 13, 2018

zkat added :semver-major and removed :under-discussion labels Jul 24, 2018

iarna previously requested changes Jul 24, 2018

View reviewed changes

hzoo mentioned this pull request Aug 6, 2018

Split @babel/runtime into 2 modules via @babel/runtime-corejs2 babel/babel#8266

Merged

add implementation details

d5a5cda

zkat approved these changes Jan 10, 2019

View reviewed changes

Rename 0002-no-caret-prerelease-installs.md to 0008-no-caret-prerelea…

77d9f86

…se-installs.md

zkat merged commit 7f6e9ff into npm:latest Jan 10, 2019

zkat added the :ratified label Jan 10, 2019

SimenB reviewed Jan 10, 2019

View reviewed changes

SimenB mentioned this pull request Jan 11, 2019

chore: consistently reference @babel/core #31

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Create 0002-no-caret-prerelease-installs.md #14

Create 0002-no-caret-prerelease-installs.md #14

hzoo commented Jul 6, 2018 •

edited

Loading

zkat left a comment

zkat Jul 6, 2018

hzoo Jul 6, 2018

iarna commented Jul 6, 2018 •

edited

Loading

hzoo commented Jul 6, 2018 •

edited

Loading

ljharb commented Jul 7, 2018

hzoo commented Jul 7, 2018 •

edited

Loading

iarna left a comment

trusktr commented Aug 8, 2018

zkat commented Dec 20, 2018

hzoo commented Dec 21, 2018

zkat left a comment

SimenB Jan 10, 2019

hzoo Jan 11, 2019

SimenB Jan 11, 2019 •

edited

Loading


		## Detailed Explanation

		`npm install`, when writing to `package.json` (like with `--save` or `--save-dev`), should check with semver and only add the `^` if the version isn't a prerelease. I don't believe it should affect anything else.

Create 0002-no-caret-prerelease-installs.md #14

Create 0002-no-caret-prerelease-installs.md #14

Conversation

hzoo commented Jul 6, 2018 • edited Loading

Rendered: https://github.com/hzoo/rfcs-1/blob/patch-2/0002-no-caret-prerelease-installs.md

zkat left a comment

Choose a reason for hiding this comment

zkat Jul 6, 2018

Choose a reason for hiding this comment

hzoo Jul 6, 2018

Choose a reason for hiding this comment

iarna commented Jul 6, 2018 • edited Loading

hzoo commented Jul 6, 2018 • edited Loading

ljharb commented Jul 7, 2018

hzoo commented Jul 7, 2018 • edited Loading

iarna left a comment

Choose a reason for hiding this comment

trusktr commented Aug 8, 2018

zkat commented Dec 20, 2018

hzoo commented Dec 21, 2018

zkat left a comment

Choose a reason for hiding this comment

SimenB Jan 10, 2019

Choose a reason for hiding this comment

hzoo Jan 11, 2019

Choose a reason for hiding this comment

SimenB Jan 11, 2019 • edited Loading

Choose a reason for hiding this comment

hzoo commented Jul 6, 2018 •

edited

Loading

iarna commented Jul 6, 2018 •

edited

Loading

hzoo commented Jul 6, 2018 •

edited

Loading

hzoo commented Jul 7, 2018 •

edited

Loading

SimenB Jan 11, 2019 •

edited

Loading