Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.
Sign upGitHub is where the world builds software
Millions of developers and companies build, ship, and maintain their software on GitHub — the largest and most advanced development platform in the world.
Add flight specific entry point for react package #20304
Conversation
This configures the Flight fixture to use the "react-server" environment. This allows the package.json exports field to specify a different resolution in this environment. I use this in the "react" package to resolve to a new bundle that excludes the Hooks that aren't relevant in this environment like useState and useEffect. This allows us to error early if these names are imported. If we actually published ESM, it would we a static error. Now it's a runtime error. You can test this by importing useState in Container.js which is used by the client and server.
|
This pull request is automatically built and testable in CodeSandbox. To see build info of the built libraries, click here or the icon next to each commit SHA. Latest deployment of this branch, based on commit 5413001:
|
| "./build-info.json": "./build-info.json", | ||
| "./jsx-runtime": "./jsx-runtime.js", | ||
| "./jsx-dev-runtime": "./jsx-dev-runtime.js", | ||
| "./": "./" |
sebmarkbage
Nov 20, 2020
Author
Member
The exports protocol is an allow list so we must list everything we want to expose here. That's actually great because we can explicitly forbid deep linking. Unfortunately our build tooling is using this same file to find things so we need to export everything until we fix that.
The exports protocol is an allow list so we must list everything we want to expose here. That's actually great because we can explicitly forbid deep linking. Unfortunately our build tooling is using this same file to find things so we need to export everything until we fix that.
Details of bundled changes.Comparing: 89d4fe1...5413001 react
Size changes (stable) |
| "unstable-cache.js" | ||
| ], | ||
| "main": "index.js", | ||
| "exports": { | ||
| ".": { | ||
| "react-server": "./unstable-index.server.js", |
acdlite
Nov 20, 2020
Member
Didn't know this feature existed, that's cool
Didn't know this feature existed, that's cool
bvaughn
Nov 20, 2020
Contributor
Was thinking the same thing. Just finished reading about it myself.
Was thinking the same thing. Just finished reading about it myself.
|
Note that this would have implications if we publish a minor from this branch. |
Details of bundled changes.Comparing: 89d4fe1...5413001 react
React: size: 0.0%, gzip: -0.0% Size changes (experimental) |
|
Oh yeah. Prefix it? |
|
Throwing in the stable channel seems fine, though |
|
It’s prefixed but the package json changes can’t be prefixed in case the resolution causes breakages. |
sebmarkbage
merged commit d93b58a
into
facebook:master
|
The "react-server" name is confusing because it doesn't apply to SSR, but we decided to settle on that. SSR is not "server environment". It's an "emulated client environment". |
|
Unfortunately it doesn't make sense to add a "react-client" resolution. That's just the default. Even if we did in some new tooling, React in general isn't that opinionated about configuring this stuff so not all environments would resolve it. |
This configures the Flight fixture to use the "react-server" environment.
This allows the package.json exports field to specify a different resolution in this environment.
I use this in the "react" package to resolve to a new bundle that excludes the Hooks that aren't relevant in this environment like useState and useEffect.
This allows us to error early if these names are imported. If we actually published ESM, it would we a static error. Now it's a runtime error.
You can test this by importing useState in Container.js which is used by the client and server.
We might need to also specify imports because jsx-runtime imports our own entry point.