How do we handle experimental releases / channels? (e.g. react@experimental, react-relay@experimental?)

[tony]

• I have read the list of known issues before filing this issue.
• I have searched for similiar issues before filing this issue.

• node version: 12.13.0
• npm version: 6.13.0
• npm-check-updates version: 3.2.1

---

Backstory: react and relay both have "channels" for experimental releases

react: https://reactjs.org/blog/2019/10/22/react-release-channels.html
react-relay: https://relay.dev/docs/en/experimental/step-by-step#step-4-adding-relay-to-our-project

In npm:

{
  "dependencies": {
    "react": "^0.0.0-experimental-38dd17ab9",
    "react-dom": "^0.0.0-experimental-38dd17ab9",
    "react-relay": "^0.0.0-experimental-a1a40b68"
  }
}

What I get:

[====================] 54/54 100%

 react        ^0.0.0-experimental-38dd17ab9  →  ^16.11.0
 react-dom    ^0.0.0-experimental-38dd17ab9  →  ^16.11.0
 react-relay   ^0.0.0-experimental-a1a40b68  →    ^7.1.0

What I expect: looking for the newest experimental ref or ignoring em. Not sure.

[raineorshine]

16.11.0 is higher than 0.0.0, so unfortunately ncu will always suggest it over the experimental versions as they have published them. Since they are on a persistent tag, I would suggest running ncu with -x react and then running npm install react@experimental separately.

I do not believe there is a deterministic way to tell that ^0.0.0-experimental-38dd17ab9 is newer than 16.11.0. There could just as easily be a ^17.0.0-experimental that is newer. In fact, that would arguably be a better version for them to use for experimental versions after 16.11.0 since it properly reflects the relative quantitative relationship. I am open to other thoughtful comments on this subject, especially if I am missing something.

[tony]

My stop gap is this: ncu -u -x react,react-relay,react-dom

The primary issue is they decided to break semver compatibility. Since it's breaking standard, introducing a new default behavior may be tricky. 0\.0\.0-.* could be a version pattern worth ignoring.

React release channels admits "prereleases" (e.g. next and experimental) break semver

All releases are published to npm, but only Latest uses semantic versioning. Prereleases (those in the Next and Experimental channels) have versions generated from a hash of their contents, e.g. 0.0.0-1022ee0ec for Next and 0.0.0-experimental-1022ee0ec for Experimental. (https://reactjs.org/blog/2019/10/22/react-release-channels.html)

I wonder if 0.0.0

Aside: Semver v2 treats 0.y.z different, kinda

Apparently semver v2 has a connotation with 0.y.z: https://semver.org/

Major version zero is all about rapid development. If you’re changing the API every day you should either still be in version 0.y.z or on a separate development branch working on the next major version.

Related issues: sindresorhus/semver-regex#13, semver/semver#363

[stoically]

FWIW, it's possible to specify the tag name as version in the dependencies. That way you always get the latest version and ncu ignores it because it's not valid semver.

[tony]

Should we consider this an ncu issue though?

I guess I'm the only reporter of this at the moment.

If it goes out of scope of ncu, I guess there's not much we can do.

While I think this is an edgecase, it seems like a practical issue - relay / react are sticking to this @experimental styling of versioning.

[raineorshine]

I wouldn't say it's strictly out-of-scope for ncu.

Since their versioning scheme uses hashes instead of numbers, experimental versions must be compared by publish time. --newest as-is does not work obviously since it will not stay within the -experimental "channel".

Currently --filter filters on the package name. We could add an option to filter on the version, thus allowing something like ncu --filter-version experimental, getting the newest version within that channel.

Whatever the solution, I think it will have to be opt-in, as the behavior may be counterintuitive when there is a newer latest.

[raineorshine]

Closing with the revive-me tag for interested contributors. See #484.