-
Notifications
You must be signed in to change notification settings - Fork 2k
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
Publish Apollo Server packages in ESM #5627
Comments
Do you think this is related to #4983 ? |
Don't think so. The last comment on that issue is forcing webpack to bundle the CommonJS version of For my exact issue after days of debugging and the help of @ardatan this is actually how I was able to force the ESM version of resolve: {
alias: {
// Force webpack to resolve the ESM version of `graphql` for better tree
// shaking and deduplication with `apollo-server-core` CommonJS imports.
graphql$: require.resolve('graphql/index.mjs'),
},
}, If you guys decide to also publish |
Sure, I'm just asking — do you think the issue you described about multiple I'm definitely in favor of us getting this done. If I understand properly, your proposal is that the published packages will contain both ESM and CJS, so this shouldn't be a backwards-incompatible change at all, right? While it's true that the Apollo Client team has done something similar and we can crib from them, I'll note that this might get done faster if it's contributed as a PR — the core team definitely has a lot of other things on our plate right now. |
Yes, if Apollo Server had an ESM version bundled I don't think the linked issue would happen because Webpack would have just picked the ESM version of Apollo Server and also the Yes, I was suggesting publishing both the CommonJS version exactly as is today and an extra ESM version as well. So, the I'd be happy to do a PR but I'm not comfortable with the Apollo Server code base or building tools, so I'd have to learn that first and then give it a shot but right now I'm a bit busy with work and already got some delays while trying to debug my other issue. ): For now, I'm glad that you agree with having an ESM bundle out of the box. (: |
@alfaproject @glasser You can take a look at our setup in GraphQL Tools and you can even try our bundler Bob. We'd love to help you with that if that sounds good for you :) |
Are there any updates on this? We're trying to include apollo-server-core in our ESM package but it has dynamic requires that break ESM. Not sure why these are needed |
I think I have this working at #6580 |
This will be fixed in Apollo Server 4; currently implemented on the |
Upgrading to Apollo v4 fixed these issues for me. However, I am running into the same issue when I create the |
@adikari Hi, I don't believe that |
Opened issue in Apollo federation repo apollographql/federation#2226 |
Currently, the Apollo Server packages are only published as CommonJS but a lot of libraries are starting to switch to ESM.
For people like us that use Serverless functions like AWS Lambda and like to keep our functions lean, we use bundlers to bundle our Serverless function code and dependencies.
We, specifically use Webpack and it could never really tree-shake CommonJS modules properly anyway. There has been some improvements in this regard in Webpack 5 but as far as
apollo-server-core
is concerned, it never tree shook any of it.As an example,
apollo-server-core
reexports some things likegraphql-tag
or@graphql-tools
which would be ok but since these libraries are now publishing in ESM, webpack no longer mixes CommonJS with ESM when bundling so we end up with duplicate packages in our bundles.Again, that would be ok, except we now have a problem with
graphql
also being bundled twice due toapollo-server-core
being bundled in CommonJS mode which in turn imports the CommonJS version ofgraphql
and then our own use ofgraphql
in ESM mode is also bundled because a library like@graphql-tools
now has ESM and importsgraphql
in ESM mode, so voila we have 2 versions ofgraphql
. This is just an example but you can basically see the whole dependency tree of Apollo Server being in a similar weird state.To make things worse, we also use
@graphql-tools
for stitching and therefore import their library as well, so we actually end up with duplicates of@graphql-tools
as well because Apollo reexports the CommonJS version. Let me show that with a screenshot of our gateway bundle analysis:The left side is pretty much all CommonJS modules (or their ESM dependencies) that webpack couldn't quite tree shake safely, and the right side is pretty much all the ESM dependencies that specific lambda is importing and could be concatenated and tree shaken safely. A few points in this screenshot for my plea above:
apollo-server-core
in the bottom left you will notice that the CommonJS version of@graphql-tools/*
was bundled and on the right you will see that the ESM version was also bundled, that's because we also import it and ESM has always priority for better tree-shaking, so this is the first duplicate that bothers me.apollo-server-core
is CommonJS only then you will also notice that@graphql-tools/mock
is also bundled even though this is a production bundle and Webpack can't get rid of it due to it being CommonJS I assume.graphql
are bundled twice, one in CommonJS (.js
) and another in ESM (.mjs
). If you pay close attention to thegraphql
bundle on the top right you will see those duplicate files.None of these points have been bothering me that much because we have been able to keep our gateway smaller than 3mb even with really bad tree shaking, but point number 3 just made us ran into a really weird and difficult to debug edge case that I have been debugging the past few days (ardatan/graphql-tools#3386)
Sorry for the long thread but I hope I can at least convince you guys to consider bundling an ESM version of Apollo Server. I know you guys know how to do it because you are already doing it for Apollo Client and the node ecosystem is moving quite steadily into ESM, so I think this might be the right time. If nothing else, you would make all the Serverless users a happy bunch. <3
The text was updated successfully, but these errors were encountered: