Make it easier to use alpha/beta versions

[slorber]

Hi,

I think it should be easier to try/use a beta version of React (like 0.14.0-beta2).

Lack of documentation

As the changes are not yet officially documented, it would be nice to have a github issue per beta where the community could discuss migration problems. Usually, the errors/warnings provided by React are quite explicit but a place to discuss this could also help, and give an insight of the amount of work needed to migrate before the attempt.

No JsFiddle

I think it would be nice to provide a base JsFiddle integration for beta versions. It would permit users to test the new React behavior in a sandbox, but also to report bugs of the beta versions more easily.

peerDependency problem

When using libs that declare React as a peerDependency, there is a problem with NPM because -betaX does not match any semver range (see npm/npm#7330 (comment))

This forces the library author to use something like this, in order to be able to use a beta with the lib:

"react": ">=0.11.0 || 0.13.0-beta.1 || 0.13.0-rc1 || 0.13.0-rc2 || 0.14.0-beta1"

The problem is that on each beta published, the library authors all have to add the new beta here to support it. I mean as I'm using react-date-picker, I have to wait the lib author to allow explicitly beta2 before being able to test beta2 (or I have to use shrinkwrap or manually edit the package.json of the lib...)

I don't know if there's a good solution to this problem, just wanted the React team to be aware of this

[syranide]

http://semver.npmjs.com/

^ or ~ solves the beta-versions, ^0.13.0-beta1 will select any 0.13.*-version following it.

[zpao]

You bring up some good points.

Lack of documentation

Absolutely. We don't document everything as we go. Sometimes we get some in there and it lands in master. We usually file an issue close to release to list out the things that still need to be documented.

As for a place to discuss, I'm not quite sure if an issue is the right place. It might be, but I want to say that this would be excellent for https://discuss.reactjs.org/ (though @spicy might tell me I'm wrong).

No JsFiddle

Yea, this hasn't been awesome. We've mostly chosen not to ship the browser builds of alphas and betas, only doing RCs and finals. Especially for 0.14 where we aren't 100% sure on what we're doing with the package (now that we're trying to split react and react-dom). We do have an unadvertised fiddle that uses the latest builds from master which I have on my server (http://react.zpao.com/builds/master/latest/). We intended to get the builds to a more sanctioned location with https but haven't yet, so go wild: https://jsfiddle.net/reactjs/ghmpo42k/

peerDependency problem

I think the dependency problem is "solved" using the pattern @syranide mentioned, but it can still be annoying. I've used "react": "^0.13.0 || ^0.14.0-beta1" and I'm pretty sure it's working. Though if it's not that's unfortunate. We do publish to the next tag. Perhaps we could also tag with next-0.14 so you can at least scope (as opposed to picking up 0.15 alphas when they come out).

[rexxars]

Might be of interest to note that npm3 will make the peer dependency problem less problematic by making it a warning instead of an error.

[slorber]

thanks for all these infos.

About https://discuss.reactjs.org/ just discovered it. It seems there are quite a bunch of spammers :)

@zpao the JsFiddle you give, is it always the same address for the latest pre-release?

@syranide so it seems your solution works but unfurtunatly it still force library authors to update the package.json (at least to add the first beta). Nice to know npm3 wiill be more permissive about it.

@zpao it would be nice to have a recommendation on what library authors should put in their package.json when they want to be permissive so that lib users can test it against alpha/beta.

After doing some tests I found out using something like this:

Lib:

  "peerDependencies": {
    "react": ">=0.12.0 || ^0.14.0-alpha"
  },

It seems at first to work great, and is able to select -beta2 automatically (and also a RC or stable version) if the client lib declares beta2 (or also ^0.14.0-alpha btw)

I don't exactly know how it works but it seems alpha/beta/rc are special names for semver prerelease tags. See also http://stackoverflow.com/questions/20276072/does-npm-honour-newer-prerelease-versions-in-semver

[syranide]

@syranide so it seems your solution works but unfurtunatly it still force library authors to update the package.json (at least to add the first beta). Nice to know npm3 wiill be more permissive about it.

@slorber But that's the entire point of semver and dependencies, a new version of a dependency needs to be tested before it should be used by the package. If you don't care about that then you can just specify *, no point sticking version numbers in there... Still, you can force install supposedly incompatible versions today as well, it's just more bothersome.

>=0.12.0 is a really poor idea for this reason too, you're claiming to be compatible with all future release versions and that is just not true.

[slorber]

Yes @syranide you are absolutly right in theory.

In practice library authors are not always testing/updating immediatly when a new version of React come out. My point is just that it should be simpler for lib users to test a lib against an alpha/beta, and maybe give feedback to the lib author afterward.

So what I want is basically to set a semver range for supported stable versions, but still also allow any alpha/beta/rc be used by users without having too much pain dealing with shrinkwrap.

[zpao]

It seems there are quite a bunch of spammers :)

Uggh, that's new… Let's crank the spam protection up to 11 @spicyj.

@zpao the JsFiddle you give, is it always the same address for the latest pre-release?

That is always the latest build from master, which will likely be ahead of the latest pre-release. But it is always the same address. We can update the original it if we move the location of the builds.

So what I want is basically to set a semver range for supported stable versions, but still also allow any alpha/beta/rc be used by users without having too much pain dealing with shrinkwrap.

Unfortunately this isn't really a problem we can realistically solve. We can make a suggestion about what to put as a dependency as mentioned for prereleases but that's still something a library author has to do. The dependency management is all npm here. I mentioned the next tag that we're publishing to. Perhaps >=0.12.0 || next will work?

[slorber]

@zpao I did try to use next like you said but it did not work. Also tried to use next in my own package.json, and next in peerDependency.

npm WARN package.json Stample@0.0.4 No repository field.
npm WARN package.json Stample@0.0.4 license should be a valid SPDX license expression
npm ERR! Linux 3.5.0-54-generic
npm ERR! argv "/home/sebastien/Desktop/devhome/install/node-v0.12.5-linux-x64/bin/node" "/home/sebastien/Desktop/devhome/install/node-v0.12.5-linux-x64/bin/npm" "install"
npm ERR! node v0.12.5
npm ERR! npm  v2.11.2
npm ERR! code EPEERINVALID

npm ERR! peerinvalid The package react does not satisfy its siblings' peerDependencies requirements!
npm ERR! peerinvalid Peer atom-react@0.13.20 wants react@>=0.12.0 || next
npm ERR! peerinvalid Peer react-date-picker@2.0.15 wants react@>=0.12.0 || next

npm ERR! Please include the following file with any support request:
npm ERR!     /home/sebastien/Desktop/Stample-react/npm-debug.log

Moving the peerDependency of my libs to a normal dependency, it seems to work with a warning:

npm WARN package.json Stample@0.0.4 No repository field.
npm WARN package.json Stample@0.0.4 license should be a valid SPDX license expression
npm WARN unmet dependency /home/sebastien/Desktop/Stample-react/node_modules/atom-react requires react@'>=0.12.0 || next' but will load
npm WARN unmet dependency /home/sebastien/Desktop/Stample-react/node_modules/react,
npm WARN unmet dependency which is version 0.14.0-beta3
npm WARN unmet dependency /home/sebastien/Desktop/Stample-react/node_modules/react-date-picker requires react@'>=0.12.0 || next' but will load
npm WARN unmet dependency /home/sebastien/Desktop/Stample-react/node_modules/react,
npm WARN unmet dependency which is version 0.14.0-beta3
react@0.14.0-beta3 node_modules/react
├── envify@3.4.0 (through@2.3.8, jstransform@10.1.0)
└── fbjs@0.1.0-alpha.4 (whatwg-fetch@0.9.0, promise@7.0.4, core-js@1.0.1)

I'm not sure how to use the tags in NPM (2.11.2) but it seems NPM has not a very consistent behavior. It would expect it to be more flexible regarging peerDependency than normal dependencies

[slorber]

Notice that using next in my app, and ^0.14.0-alpha in peerDependency of the libs, I'm able to get the new react@0.14.0-beta3. It is not ideal but seems to be the more flexible option for lib authors that want to support all alpha/beta/rcs of a given version

[cesarandreu]

Adding to this: would you consider tagging alpha/beta releases?

Looking at the diff between versions makes it a bit easier to figure out what changed, so you're more inclined to try out early releases. Otherwise you need to track down the specific commits, which is tedious.

[yiminghe]

A little notice:

~x.y.z-beta9  will match x.y.z-beta9 not x.y.z-beta10(if exists).

Better to use x.y.z-beta.q

[zpao]

I didn't expect that but on rereading that part of the spec, it's right there.

Precedence for two pre-release versions with the same major, minor, and patch version MUST be determined by comparing each dot separated identifier from left to right until a difference is found as follows: identifiers consisting of only digits are compared numerically and identifiers with letters or hyphens are compared lexically in ASCII sort order

And backed up with the semver module (tested with caret ranges since those are default):

> s.satisfies('0.15.1-beta9', '~0.15.1-beta9')
true
> s.satisfies('0.15.1-beta10', '~0.15.1-beta9')
false
> s.satisfies('0.15.1-beta.9', '~0.15.1-beta.9')
true
> s.satisfies('0.15.1-beta.10', '~0.15.1-beta.9')
true
> s.satisfies('0.15.1-beta9', '^0.15.1-beta9')
true
> s.satisfies('0.15.1-beta10', '^0.15.1-beta9')
false
> s.satisfies('0.15.1-beta.9', '^0.15.1-beta.9')
true
> s.satisfies('0.15.1-beta.10', '^0.15.1-beta.9')
true

[krzysiek1507]

https://github.com/npm/node-semver#prerelease-identifiers

[aweary]

I'm going to close this out because I don't think there's anything actionable here, and there's been no activity for over a year.

For the React 16 release, the team has been maintaining a detailed, and up-to-date issue for the betas and RC. A JSFiddle could easily be included in this and future issues tracking releases, thanks to unpkg. I don't think there's any intention to break from the current versioning practices for prereleases.