ESM build for the browser #2277
Conversation
We used only couple functions from 'iterall' and it's the only dependency we have at the moment. Having no dependencies significantly simplify ESM builds and Deno support in future Partially resolves: graphql#2277 Bonus: All supported Node versions already natively support Array.from so it should improve perfomance
We used only couple functions from 'iterall' and it's the only dependency we have at the moment. Having no dependencies significantly simplify ESM builds and Deno support in future Partially resolves: #2277 Bonus: All supported Node versions already natively support Array.from so it should improve perfomance
| @@ -11,7 +11,8 @@ declare function instanceOf( | |||
|
|
|||
| // See: https://expressjs.com/en/advanced/best-practice-performance.html#set-node_env-to-production | |||
| // See: https://webpack.js.org/guides/production/ | |||
| export default process.env.NODE_ENV === 'production' | |||
| export default typeof process !== 'undefined' && | |||
| process.env.NODE_ENV === 'production' | |||
There was a problem hiding this comment.
@lukejacksonn Can you please extract it into separate PR?
Also, please test that Webpack is able to recognize this pattern and switch to the production code.
Is it the last change we need to support ESM?
There was a problem hiding this comment.
Yeh I can do that.. this is the last source modification required for ESM support (assuming that the mjs build now adds extensions to imports paths).
There was a problem hiding this comment.
Yeh I can do that..
Great 👍 Thanks a lot!
assuming that the mjs build now adds extensions to imports paths
You can see preview build here:
https://github.com/graphql/graphql-js/blob/npm/graphql.mjs
If you have time to try it here is the instruction:
https://github.com/graphql/graphql-js#want-to-ride-the-bleeding-edge
There was a problem hiding this comment.
Hi @lukejacksonn,
Did you have a time to test this change with webpack?
I planning to release new RC so it would be great to also include this change.
There was a problem hiding this comment.
Hey @IvanGoncharov sorry this task completely slipped my mind. I have made a PR #2409 but am not so sure about what webpack specific config needs to be checked
|
Superseded by #2409 |
Hey 👋 I'm a big advocate of buildstep-less architectures on the web, taking advantage of ES modules to eschew the need for bundling (es-react for example). This PR addresses #1819.
💭 Rationale
Recently I wanted to use urql in one of my projects that falls into this build free category. So I set about picking apart the dependencies of the package to see how far it was from being ESM ready. Probably unsurprisingly this package is the biggest dependency of urql so I started with fixing it up and this is what I ended up working with.
👨🔧 Changes
esmwith a custom babel extension that appends.es.jsto import/export statement sources. The differences between this andmjsbuild are subtle but this decision was made as not to disturb any existing builds. Explicit extensions are required according to the browser es module spec (also the most recent node es module spec).typeof processininstanceOf.jsto preventCannot find property .env of undefinederror when running the browser; without altering the node behaviour.iterallpackage to eradicate the only bare specifier import and making the whole codebase dependency free!/index.jsresolvable by extension only (due to/depencendy.jsand/dependency/index.jsinconsistency usually handled by nodes resolution algorithm)📦 Output
This PR itself is a POC that I made for myself, I'm not precious about the implementation details but I am quite optimistic about the results.
Here is a published version of this PR: https://www.runpkg.com/?es-graphql@1.0.3/dist/index.es.js
Here is a demo of this build working with urql: https://es-urql.lukejacksonn.now.sh
Running
yarn build && yarn testonlycurrently succeeds with no errors but type checking fails due to no definitions for the functions withiniterall.js. If anyone has suggestions of how to achieve the same result with a different approach to any of the steps outlined by specific commits here, then I am all ears (I am no babel aficionado)!🤔 Conclusion
This library required very few changes in order to make it just work in the browser. I'm almost certain that this would trivialise and encourage gql client library authors to generate es module builds themselves which will lower the barrier to entry for people getting started with GraphQL in general (example projects could now just be an index.html with no install or build process to explain).