-
Notifications
You must be signed in to change notification settings - Fork 47k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add exports field to react-dom (including configuring Cloudflare and Deno) #23252
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This seems like the aspirational goal we want though and to avoid breaking changes it seems worth landing. For example, Deno in Node compat mode should still use the browser build.
I think we should do a full e2e test: set-up fake npm registry, install packages, run a smoke test. Don't need to run it on every commit, maybe just before a release or in a cron job.
"./profiling": "./profiling.js", | ||
"./test-utils": "./test-utils.js", | ||
"./package.json": "./package.json", | ||
"./": "./" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We know that this pattern is deprecated and it'll be removed from builds in another PR.
Comparing: 9d4e8e8...f8986bb Critical size changesIncludes critical production bundles, as well as any change greater than 2%:
Significant size changesIncludes any change greater than 0.2%: (No significant changes) |
This configures the exports field for react-dom. Notably there are some conditions for the /server entry point where we pick the export based on environments. Most environments now support Web Streams which is preferred in those environments. We already do this using the "browser" field so the "browser" condition applies here too. I don't think it's necessary, but I also specified "worker" explicitly since this is for Service Workers and those are often targeted with Web Pack's "webworker" target, which is also what Cloudflare currently recommends. I also added "deno" but deno is a bit special because this only works if you run with the node compatibility since otherwise you have to specify absolute URLs for the imports.
82126b8
to
f8986bb
Compare
The issue with Deno is that the idiomatic way to consume react is probably through intermediate hosts that rewrite them to ESM automatically. Such as this one: https://jspm.dev/react@next So a fake npm registry wouldn't even be enough. |
This configures the exports field for react-dom. Notably there are some conditions for the /server entry point where we pick the export based on environments. Most environments now support Web Streams which is preferred in those environments. We already do this using the "browser" field so the "browser" condition applies here too. I don't think it's necessary, but I also specified "worker" explicitly since this is for Service Workers and those are often targeted with Web Pack's "webworker" target, which is also what Cloudflare currently recommends. I also added "deno" but deno is a bit special because this only works if you run with the node compatibility since otherwise you have to specify absolute URLs for the imports.
This configures the exports field for react-dom.
Notably there are some conditions for the /server entry point where we pick the export based on environments. Most environments now support Web Streams which is preferred in those environments.
We already do this using the "browser" field so the "browser" condition applies here too.
I also specified "worker" explicitly since this is for Service Workers and those are often targeted with Webpack's "webworker" target, which is also what Cloudflare currently recommends. I don't think this is necessary because Webpack includes the "browser" field for this case. However, it seems more accurate. Although I'm not sure if this would break if you use a Worker in Node.js.
I also added "deno" but Deno is a bit special because this only works if you run with the node compatibility on since otherwise you have to specify absolute URLs for the imports anyway. Currently the node compatibility doesn't work well from real ESM and the built-in JSX support doesn't work outside of real ESM. So this is a bit of a mess.
I wasn't able to add fixtures and test any of this yet. It ended up being kind of messy and a lot of work to create a real environment. This seems like the aspirational goal we want though and to avoid breaking changes it seems worth landing. For example, Deno in Node compat mode should still use the browser build.