Use automatic react runtime for v18.0.0

[alexeyraspopov]

↪️ Pull Request

When using react@next and react-dom@next, NPM installs v18.0.0-alpha-XXXXXXX. Parcel uses >= 17.0.0 to determine whether to use automatic runtime or React.createElement. The check fails for v18.x probably because of semver: >=17.0.0 does not go beyond the major release.

🚨 Test instructions

Using a fresh nightly build parcel@^2.0.0-nightly.838 with react@^18.0.0-alpha-a8cabb564-20210915 (and similar react-dom, or simply react@next), writing any JSX without import React from 'react' throws an error React is not defined in browser.

✔️ PR Todo

• Added/updated unit tests for this change
• Filled out test instructions (In case there aren't any unit tests)
• Included links to related issues/PRs

[height]

Link Height tasks by mentioning a task ID in the pull request title or description, commit messages, or comments.

💡Tip: You can also use "Close T-X" to automatically close a task when the pull request is merged.

[mtgto]

The check fails for v18.x probably because of semver: >=17.0.0 does not go beyond the major release.

It seems to be a bit wrong. The problem is semver.satisfies returns false when target version is prerelease.

I test with RunKit.
https://npm.runkit.com/semver

console.log(semver.satisfies('18.0.0', '>= 17.0.0')); // true
console.log(semver.satisfies('18.0.0-alpha-a8cabb564-20210915', '>= 17.0.0')); // false

BTW, I suggest to use coercion of semver to compare versions including prelease libraries.

console.log(semver.valid(semver.coerce('18.0.0-alpha-a8cabb564-20210915'))); // "18.0.0"
console.log(semver.satisfies(semver.valid(semver.coerce('18.0.0-alpha-a8cabb564-20210915')), '>= 17.0.0')); // true

[alexeyraspopov]

@mtgto, I do agree coerce() makes sense. I guess the issue will be resolved once v18 is released, so there will be no need to update the version range, but every following alpha/beta/rc/nightly will keep breaking the condition

[mischnic]

This looks like a cleaner solution:

require("semver").satisfies("18.0.0-rc.0-next-13036bfbc-20220121", ">= 17.0.0", {includePrerelease: true})
===
true

@alexeyraspopov Could you fix that?

[gaearon]

The approach doesn’t seem ideal because it won’t work for 0.0.0 versions tagged as @experimental. I’d suggest checking for the presence of /jsx-runtime entry point in the package.

[mischnic]

We don't really want to do a path resolution for every single asset to determine this. I think it's safe to assume that using an experimental React version means that it's a recent one which supports the automatic runtime (and if not, these very few projects could still use the manualy jsconfig setting). So the check should be something like
>=17 (including prereleases) OR 0.0.0 (including prereleases)

[gaearon]

Fair.

[gaearon]

for every single asset

(I don't understand this part but your approach sounds good to me too.)

[devongovett]

Opened a new PR to implement the above suggestion: #7642