This condition is different than one used in other places - because this one has <15.0.0-canary.24 without lower limit, it will actually match 14.2.5 for example (tho we won't be really hitting those edge cases with the version we test setup as all currently tested version would have private directive (13.5.1, latest which is now 14.2.11 and canary which is now 15.0.0-canary.157)

This would work (and then probably same condition should be used across the board? maybe we centralize it and add shouldHavePrivateDirective to same helper module that already has nextVersionSatisfies helper?)

Or we use the condition used elsewhere with understanding that those earlier canary versions (>=15.0.0-canary.0 <15.0.0-canary.24) generally should have private directive but we skip those because we don't really test those anymore and keeping condition cleaner and easier to reason with

Interesting. I've read those semver docs a hundred times and I still keep finding things I've misinterpreted. I thought prerelease range specifiers could never match stable releases (and prereleases with a different prefix).

That clearly wasn't right:

$ npm i -g semver
$ semver -r '<15.0.0-canary.24' '14.2.5' '15.2.5' '15.0.0-canary.20' '15.0.0-canary.30'
14.2.5
15.0.0-canary.20

Fascinating:

$ semver -r '<15.0.0' 15.0.0-canary.150
15.0.0-canary.150

Maybe this was obvious to you, but I thought this behaved kind of like JS's comparison operators with values like NaN:

> 3 < NaN
false
> 3 > NaN
false

It's a bit more nuanced (or maybe some other word that could fit here better 🙃 ):

semver -r '<15.0.0-canary.24' '14.2.5' '14.2.5-canary.5' '15.2.5'  '15.0.0-canary.20' '15.0.0-canary.30'
14.2.5
15.0.0-canary.20

The 14.2.5-canary.5 wouldn't match but 14.2.5 would ... unless you would use includePrerelease:

semver --include-prerelease -r '<15.0.0-canary.24' '14.2.5' '14.2.5-canary.5' '15.2.5'  '15.0.0-canary.20' '15.0.0-canary.30'
14.2.5-canary.5
14.2.5
15.0.0-canary.20

maybe we centralize it and add shouldHavePrivateDirective to same helper module that already has nextVersionSatisfies helper?

I had thought about that, but strangely we'd need two different versions of it (some assertions are affected by the change a few months ago, some are affected by both changes) and I couldn't come up with a reasonable name for these functions I decided this was a case of "a poor abstraction is worse than no abstraction".

It's a bit more nuanced [...]

Somehow I knew about that nuance but not the more fundamental one above!