facebook / react

* Call into Fabric to get current event priority

Fix flow errors

* Prettier

* Better handle null and undefined cases

* Remove optional chaining and use ?? operator

* prettier-all

* Use conditional ternary operator

* prettier

This does not mean that a release of 18.0 is imminent, only that the
main branch includes breaking changes.

Also updates the versioning scheme of the `@next` channel to include
the upcoming semver number, as well as the word "alpha" to indicate the
stability of the release.

- Before:       0.0.0-e0d9b28999
- After:        18.0.0-alpha-e0d9b28999

…ion Order (#21642)

* Add a DEV warning for common case

* Don't set Pending flag before we know it's a promise

* Move default exports extraction to render phase

This is really where most unwrapping happen. The resolved promise is the
module object and then we read things from it.

This way it lines up a bit closer with the Promise model too since the
promise resolving to React gets passed this same value.

If this throws, then it throws during render so it's caught properly and
you can break on it and even see it on the right stack.

* Check if the default is in the module object instead of if it's undefined

Normally we'd just check if something is undefined but in this case it's
valid to have an undefined value in the export but if you don't have a
property then you're probably importing the wrong kind of object.

* We need to check if it's uninitialized for sync resolution

Co-authored-by: Dan Abramov <[email protected]>

Co-authored-by: HuJiajie <[email protected]>

* Implement component stacks

This uses a reverse linked list in DEV-only to keep track of where we're
currently executing.

* Fix bug that wasn't picking up the right stack at suspended boundaries

This makes it more explicit which stack we pass in to be retained by the
task.

This has been ramped up to 80% GK so the next step is to just turn it on for 100%

Since we track these versions in source, we can build `@latest`
releases in CI and store them as artifacts.

Then when it's time to release, and the build has been verified, we use
`prepare-release-from-ci` (the same script we use for `@next` and
`@experimental`) to fetch the already built and versioned packages.

Now that we track package versions in source, `@latest` builds should
be fully reproducible for a given commit. We can prepare the packages in
CI and store them as artifacts, the same way we do for `@next` and
`@experimental`.

Eventually this can replace the interactive script that we currently
use to swap out the version numbers.

The other nice thing about this approach is that we can run tests in CI
to verify that the packages are releasable, instead of waiting until
right before publish.

I named the output directory `oss-stable-semver`, to distinguish from
the `@next` prereleases that are located at `oss-stable`. I don't love
this naming. I'd prefer to use the name of the corresponding npm dist
tag. I'll do that in a follow-up, though, since the `oss-stable` name is
referenced in a handful of places.

Current naming (after this PR):

- `oss-experimental` → `@experimental`
- `oss-stable` → `@next`
- `oss-stable-semver` → `@latest`

Proposed naming (not yet implemented, requires more work):

- `oss-experimental` → `@experimental`
- `oss-next` → `@next`
- `oss-latest` → `@latest`

Instead of keeping a separate allowlist in sync, we use ReactVersions.js
as the source of truth for which packages get published.

Co-authored-by: Brian Vaughn <[email protected]>

Follow-up to #21608

The versioning scheme for `@next` releases does not include semver
information. Like `@experimental`, the versions are based only on the
hash, i.e. `0.0.0-<commit_sha>`. The reason we do this is to prevent
the use of a tilde (~) or caret (^) to match a range of
prerelease versions.

For `@experimental`, I think this rationale still makes sense — those
releases are very unstable, with frequent breaking changes. But `@next`
is not as volatile. It represents the next stable release. So, I think
we can afford to include an actual verison number at the beginning of
the string instead of `0.0.0`.

We can also add a label that indicates readiness of the upcoming
release, like "alpha", "beta", "rc", etc.

To prepare for this the new versioning scheme, I updated the build
script. However, **this PR does not enable the new versioning scheme
yet**. I left a TODO above the line that we'll change once we're ready.

We need to specify the expected next version numbers for each package,
somewhere. These aren't encoded anywhere today — we don't specify
version numbers until right before publishing to `@latest`, using an
interactive script: `prepare-release-from-npm`.

Instead, what we can do is track these version numbers in a module. I
added `ReactVersions.js` that acts as the single source of truth for
every package's version. The build script uses this module to build the
`@next` packages.

In the future, I want to start building the `@latest` packages the same
way we do `@next` and `@experimental`. (What we do now is download a
`@next` release from npm and swap out its version numbers.) Then we
could run automated tests in CI to confirm the packages are releasable,
instead of waiting to verify that right before publish.

* Resolve the entry point for tests the same way builds do

This way the source tests, test the same entry point configuration.

* Gate test selectors on www

These are currently only exposed in www builds

* Gate createEventHandle / useFocus on www

These are enabled in both www variants but not OSS experimental.

* Temporarily disable www-modern entry point

Use the main one that has all the exports until we fix more tests.

* Remove enableCache override that's no longer correct

* Open gates for www

These used to not be covered because they used Cache which wasn't exposed.

* Convert ES6/TypeScript CoffeeScript Tests to createRoot + act

* Change expectation for WWW+VARIANT because the deferRenderPhaseUpdateToNextBatch flag breaks this behavior

We're still experimenting with this and it causes a breaking behavior
for setState in componentWillMount/componentWillReceiveProps atm.

* [Offscreen] Mount/unmount layout effects

Exposes the Offscreen component type and implements basic support for
mount/unmounting layout effects when the visibility is toggled.

Mostly it works the same way as hidden Suspense trees, which use the
same internal fiber type. I had to add an extra bailout, though, that
doesn't apply to the Suspense case but does apply to Offscreen
components: a hidden Offscreen tree will eventually render at low
priority, and when we it does, its `subtreeTag` will have effects
scheduled on it. So I added a check to the layout phase where, if the
subtree is hidden, we skip over the subtree entirely. An alternate
design would be to clear the subtree flags in the render phase, but I
prefer doing it this way since it's harder to mess up.

We also need an API to enable the same thing for passive effects. This
is not yet implemented.

* Add test starting from hidden

Co-authored-by: Rick Hanlon <[email protected]>

Co-authored-by: Dan Abramov <[email protected]>

* Define global __WWW__ = true flag during www tests

We already do that for __PERSISTENT__.

* Use @GATE www in ReactSuspenseCallback

This allows it to not be internal anymore. We test it against the www build.