-
Notifications
You must be signed in to change notification settings - Fork 86
Conversation
Since rollup prefers ESM formatted modules, it should look for node's new .mjs file extension before looking for .js files by default. This offers support for deployed modules intended to be used in node's ESM mode. Folks can work around this today by manually supplying the `extensions` option, however it would be great if this worked by default. Note that looking for `.mjs` before `.js` is important for rollup which prefers ESM, however the `resolve` dependency should not use the same order by default since it is used in many other tools which do not yet support ESM or would not expect it by default. Encountered this as the root cause behind graphql/graphql-js#1293
Ping on this - this unfortunately still blocks use of Rollup for anyone using GraphQL or any other native ESM module. |
Why graphql just didn't use existing |
@TrySound, while packagers like Rollup and Webpack use the module field, it’s not how node’s native module loader designed. Part of the issues is that it is not just the entry point into a package that can be differentiated but also any other file or subpath into a package. I know the team working on a native module loader considered all of these issues when arriving to the .mjs behavior. This PR doesn’t affect the existing support for a package’s top level module field, but adds support for packages built in a “dual mode” way. This is a good article capturing all of that in a much deeper way than I’ve done here and further explaining “dual mode” https://medium.com/@giltayar/native-es-modules-in-nodejs-status-and-future-directions-part-i-ee5ea3001f71 |
Cc @keithamus @Rich-Harris any chance you could include this in a next release? |
Thank you. |
Is this feature released? I am still not able to use graphql/ApolloServer with rollup. |
Just shipped |
he, in some package.json props of my latest libraries...
NodeJS |
@aMarCruz I don't recommend to keep UMD in
A lot of uber packages use Also use please |
@TrySound thanks, I'm already documenting the unpkg link in the Readme, but you may right and I'm thinking about to remove the "browser" field and adopt your recomendations for the rest. The |
Well do you agree this is weird? es2015 is es6, es2016 is es7. Sticking with specific version is confusing. |
my bad, it is for ESM+ES6, but I agree, it is something strange comming from Google. added: this are the formarts that I'm using: https://github.com/ProJSLib/jsbits#distribution-formats |
For those following the breadcumbs of why graphql can't be used with rollup, although the index.mjs file is loaded from graphql, it re-exports from a bunch of sub-modules, each of which has both a rollup seems to always check for index.js first and use it if it exists. My solution, pre-running rollup, I do:
which allows rollup to pick up the index.mjs files and then it can find all of it's imports |
Since rollup prefers ESM formatted modules, it should look for node's new .mjs file extension before looking for .js files by default. This offers support for deployed modules intended to be used in node's ESM mode.
Folks can work around this today by manually supplying the
extensions
option, however it would be great if this worked by default.Note that looking for
.mjs
before.js
is important for rollup which prefers ESM, however theresolve
dependency should not use the same order by default since it is used in many other tools which do not yet support ESM or would not expect it by default.Encountered this as the root cause behind graphql/graphql-js#1293