Publishing 15.0.3 under a separate dist-tag

[ide]

React Native requires 15.0.3 which is currently published as 15.0.3-alpha.2. Installing this module leads to peerDependency warnings and errors (ex: npm shrinkwrap actually fails) because several packages have peerDeps on react@^15.0.0 and 15.0.3-alpha.2 doesn't match.

Several people including myself have raised the issue with npm but for the time being could FB publish master as 15.0.3 and use npm's dist-tag feature to tag 15.0.2 as "latest" and 15.0.3 as "next" or "at-your-own-risk"?

[syranide]

I could always recommend poking the other dependencies and have them change to ^15.0.0-0 as a peer dependency instead, that way they're also compatible with all prereleases. Then it would at least be a non-problem eventually (until npm fixes it for real), but I doubt anyone is up for releasing React as 15.0.3 as it would then be picked up by anyone updating just as if it was stable, which it isn't.

[gaearon]

I could always recommend poking the other dependencies and have them change to ^15.0.0-0 as a peer dependency instead, that way they're also compatible with all prereleases.

Alas, this doesn’t help in this case. ^15.0.0-0 matches 15.0.0-alpha.0 but not 15.0.3-alpha.0, for example. There’s just no way in semver to specify “major version and all its prereleases” AFAIK.

[syranide]

@gaearon Oh wow, my bad, you're right... sigh...

[ide]

npm's recommendation is to use dist-tags instead of prerelease versions but frankly I think that doesn't help a lot because sometimes you want to publish an unstable version like 15.0.3-alpha.1 that won't be supported, yet want to see how it works in the wild.

The next best alternative is to publish a non-prerelease version like 15.0.3, untag it as "latest", and then unpublish / deprecate 15.0.3 if it ends up being buggy. So anyway that's the situation we're in until npm changes their peerDep validation (seems unlikely) or a new npm client comes along and supports this desired behavior.

[syranide]

The next best alternative is to publish a non-prerelease version like 15.0.3, untag it as "latest", and then unpublish / deprecate 15.0.3 if it ends up being buggy.

@ide That screws over anyone depending on ^15.0.0 and such which is common practice.

npm's recommendation is to use dist-tags instead of prerelease versions but frankly I think that doesn't help a lot because sometimes you want to publish an unstable version like 15.0.3-alpha.1 that won't be supported, yet want to see how it works in the wild.

From my understanding of this (which isn't perfect), I just don't see a viable solution other than npm going back and getting things right. There are ways around it but they also violate semver and may silently ignore unintended version conflicts, which goes against the entire point of having semver in teh first place.

It seems obvious to me (at least) that npm should allow me to "force install" a specific module version at my own peril and force all dependencies to just accept it. But perhaps I'm missing something.

[ide]

Why does it screw over anyone using ^15.0.0? The dist-tag makes it opt in -- the only way you'd get 15.0.3 is by explicitly asking for that specific version.

[syranide]

Why does it screw over anyone using ^15.0.0? The dist-tag makes it opt in -- the only way you'd get 15.0.3 is by explicitly asking for that specific version.

Perhaps I just don't understand this well enough... you're saying depending on ^15.0.0 would not match 15.0.3@whatever? But 15.0.3@whatever would still satisfy peer dependencies with ^15.0.0 (which is the entire point)?

[zpao]

I knew this would be a problem…

15.0.3-alpha.2 was at next but then 15.1.0-alpha.1 superseded that. Could make it next-patch or something like that. I don't want to go down the route of publish as real versions because we'll burn through versions way too quickly as we attempt to make things work in RN.

Do dist-tags really help? You need all deps to use them too right? And then we can't break the semantics (Eg publish a "next-rn" and then move it to point to a new major version when that time comes)

[syranide]

Do dist-tags really help? You need all deps to use them too right? And then we can't break the semantics (Eg publish a "next-rn" and then move it to point to a new major version when that time comes)

If all modules include that tag in the version string then they will all by definition also announce support for the latest version (or w/e) of React, even if the module hasn't been maintained since forever and obviously doesn't. That seems equally problematic, but in a different way?

[zpao]

That seems equally problematic, but in a different way?

Perhaps not equally but definitely still a problem.

We could probably do it with some guarantees and do something like next-rn-15, much like next, however we wouldn't ever point it past 15.y.z. People would have to republish to support a new major version, but we probably want them too anyway. I think npm does something similar just without the preprelease bits which do make it harder (but shipping a client is different than shipping a library and I don't think publishing a pile of (unobviously) unsupported versions is the right thing to do)

It's still an all or nothing game though.

[ide]

you're saying depending on ^15.0.0 would not match 15.0.3@whatever? But 15.0.3@whatever would still satisfy peer dependencies with ^15.0.0 (which is the entire point)?

@syranide Exactly, that's what removing the "latest" dist-tag achieves.

If all modules include that tag in the version string

Dist-tags are separate from version strings. They're metadata on npmjs.org that control how npm install works.

@zpao The problem is that npm needs real versions unless every package maintainer with peerDependencies adds 15.0.3-0, which is obviously unsustainable. Dist-tags help because they let us publish real versions while making them be opt-in. So if 15.0.3 is full of bugs, that's OK (for some definition of OK...) because the only way you could get 15.0.3 is if package.json explicitly asked for ^15.0.3. Anyone asking for ^15.0.0 will get 15.0.2.

The solution to the root cause is for npm to fix this issue. I've thought through it a bit and I think npm's current semver behavior for peerDeps is wrong. Either they should block prerelease versions so everything has to be a real version, or someone needs to come along and write an npm client replacement, wink wink.

But until that happens, the next best solution I can think of is for react-native (and other packages that use react) not to depend on prerelease versions.

[zpao]

I don't philosophically agree with shipping seemingly "stable" versions of react that are only intended for us to try to make RN work but that we need to publish 5 times to get right.

Help me understand the scope of the problem… is it packages that RN depends on or ships with? Or is it only an issue for people building apps using RN from github? If it's the latter then I propose we don't care. Published versions of RN will point at released versions of React. Maybe that goes for RCs as well. Our plan from the React side was to ship alphas so RN can get things as quickly as possible, and then shipping the alpha as a stable release and update RN so it's final version never uses an alpha.

cc @facebook/react-core since we've been talking about this and perhaps there are some discussions around this I haven't been a part of

[ide]

I don't philosophically agree with shipping seemingly "stable" versions of react that are only intended for us to try to make RN work but that we need to publish 5 times to get right.

FWIW I'm with you philosophically. It's npm's current behavior that's the issue here.

is it packages that RN depends on or ships with? Or is it only an issue for people building apps using RN from github?

It's the latter, potentially including RCs (0.26-rc going out sometime between this Friday and Monday).

Our plan from the React side was to ship alphas so RN can get things as quickly as possible

Totally agree with this. Your plan makes a lot of sense -- it's just npm's overly strict peerDep validation that causes issues when doing more comprehensive testing of react-native@master with React + RN + react-redux, for example.

To fix the core issue we need npm to fix this upstream (npm/npm#8854 -- closed, though) or for an alternative npm client to supplant npm's.

[zpao]

It's the latter, potentially including RCs

How many people is that? I'm not sure how much I actually care to go out of our way to support a small number of people building from arbitrary points on master. Maybe we change our modus operandi for RCs though.

[ide]

Not a lot though awhile back almost everyone doing something serious with RN was using a fork of master.

Anyway if you understandably want to wait to publish 15.0.3 we'll live. It's really npm + peerDeps making things an issue here.