TLDR
Support is still experimental. Most things work as expected out of the box with a Front End application, but it had a lot of issues with Node libraries and while testing with Enzyme.
You can use them right now, but we are not there yet.
Introduction
As an ever learning developer, I'm always trying to keep up with the latest ES features and all relevant technologies on the web.
I want to tell you about two pet projects where I tried to use them and the problems that I've encountered.
Proyect 1 React, Redux Firebase Application
So I tried to migrate my app from create-react-app to something that used Parcel and supported ES Modules out of the box. Everything worked great, I just changed index.js to index.mjs. I feel like living in the future, and this is what my project looked like:
The problems arrived when I tried to integrate unit tests, I'm not sure if there is something wrong with Jest or if Parcel requires some additional configuration. What bugs me is that it is supposed to be a Blazing fast, zero configuration web application bundler, for the most part if is. I gave it a day, and I wasn't able to solve it, so I decided to move to react-boilerplate, which I really loved.
Proyect 2 The app for my puppeteer series blog post
Here is the post link if you are curious.
If you haven't checked it out, it is a NodeJS application that is meant to run on a desktop or CI server in order to do visual regression tests. According to this post, you might not need any webpack nor RollupJS anymore.
Double checking the documentation, since Node v10.x there is experimental support. If you don't know what that means, here's a link with the explanation.
Anyway, the only thing needed is to add a experimental flag, the command looks something like this:
$ node --experimental-modules main.mjs
So again, all the files you see in the repo, used to be ES Modules, but I had a problem trying to implement pixelmatch. Now don't get me wrong, the library is awesome, the problem is that ES Modules support is still experimental. The problem was that the exports where not being recognized as such within my index.mjs.
Conclusion
It was a nice experiment, I think using ES Modules is generally OK for most simple applications, they play nice with React, Parcel and most modern browsers in general, but if you have some external libraries it might break.
I would recommend it for pet projects, but not for the core of your next SaaS startup, not yet. Have you tried this or any other experimental features? How did it go?
Thanks for reading guys. Cheers.
Top comments (5)
With node it's as easy as
-r esm. I have a hard time fathoming why everyone doesn't do this.As a community, we need to stop letting node's indecision (as justified as it may be) hold us back.
Agreed.
How many people know what goes into the bundle when you write
import React, { Component } from "react"and run it through a transpiler?
How many people (besides the JS disciples) will care if it's .mjs or .js or .esm?
Now, I'm aware that there are proper geniuses in TSC, and they must have discussed this ESM thing over and over. Yet they could only come up with a new extension?
From what I could gather, the main reason for that is "backwards compatibility with commonjs". Compatibility with something that is essentially a collection of hacks?
This is the official spec, not what people made do with in the past. Who thought it was a good idea to use cjs in .js yet esm in .mjs? It should actually be the other way around, if you really want to keep the extension.
FWIW, I think the best way forward was to add something like
"use modules"at the module level.
I'm not a fan of how node is implementing the feature, I think I'll stick to transpiling with babel. Everything works fine with that.
Why not just transpile esmodules with babel? Best of both worlds
That is always an option, I wanted to explore the idea of not doing it anymore.