Skip to content
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鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

馃摝 About ESM #111

Open
xiaoxinghu opened this issue Jul 21, 2021 · 1 comment
Open

馃摝 About ESM #111

xiaoxinghu opened this issue Jul 21, 2021 · 1 comment
Labels

Comments

@xiaoxinghu
Copy link
Collaborator

xiaoxinghu commented Jul 21, 2021

Okay, let's talk about ESM.

I have been spending too much time (more than I should) to try to adopt ESM (a little bit of background here if you need more context) in some o orgajs packages. Mainly because some of the key packages that orgajs rely on is moving forward to pure ESM land. Here is a list of the major ones:

I am not going to list them all, basically, the whole unified ecosystem, and tons of useful tools are moving to ESM only right now. Which means we are frozen in time if we don't move. But there are two main reasons for us to stay in the commonjs land right now:

  1. Gatsby does not support esm plugins. This is not working and the esm package mentioned in the doc is basically dead. Here is a feature request that captures the issue.
  2. Next.js is still working on it. It seems that the PR is merged. I haven't tried it yet, will definitely revisit when it's in stable release.

Orga currently heavily rely on these two eco-systems, so until they officially support ESM, I don't feel comfortable converting the packages.

That being said, I did successfully hack my way around it by using esbuild to transpile and bundle all esm modules into a cjs one, consumed by gatsby plugins. But there are drawbacks for that approach:

  • Increased bundle size. Since the esm packages are already in dependencies, bundle them into the package double the size of the final package. Yes I can move them into devDepdencies, but it's just not nice.
  • hard to maintain the build order if using 2 compilers (typescript and esbuild), it's just clumsy
  • esbuild don't check types
  • esbuild don't support yarn plug n play (yes, I tried that, but that's a story/issue for another day)

But boy oh boy, is esbuild fast!

So after some thought, I decided to roll back the packages and lock them down to the last version before ESM. I think we are gonna have to wait it out for now.

Plan B is to revisit the esbuild solution if an official solution for gatsby is still nowhere to be seen after a while. I understand it's a major change, and I can't even pretend to understand how complicated it would be for projects like gatsby.

@ChristianMurphy
Copy link

FWIW, Next 11.1 added ESM support https://nextjs.org/blog/next-11-1#es-modules-support
There is also community driven documentation of ESM support for a number of other platforms at https://gist.github.com/sindresorhus/a39789f98801d908bbc7ff3ecc99d99c

For Gatsby, it may be possible to use dynamic import as a bridge, xdm used this approach to create a webpack loader supporting ESM https://github.com/wooorm/xdm/blob/fa8fb4918099ff085de45d03d01aa2f952228a8d/webpack.cjs

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants