Published: Dec 18, 2021
It was a lot of work, and although ESM is not quite in a perfect place yet within the ecosystem (CJS <> ESM interop and the "dual module hazard"), there were two key motivations for us that made us want to make the jump now, especially before hitting a 1.0 release.
As Greenwood expands past just static sites with our upcoming plans to add support for Server Side Rendering and External Data Sources, user's would be able to start writing server side code within their project's workspace. This meant there would be NodeJS and browser code right next to each other, and as part of Greenwood's mission to make writing sites for the web easier, taking advantage of a consolidated module system makes perfect sense for developer experience. We want the NodeJS code you have to write to be as close to the code that you write for the browser, and so for Greenwood, this means supporting ESM in NodeJS.
Additionally, libraries like Lit that provide support for SSR are themselves written in ESM and unfortunately because interop between CJS and ESM doesn't go both ways, we would not be able to support these projects if we stayed on CJS. For this reason, the first party code by users will need to be written in ESM. we also expect more packages to become ESM first / only, and so this helps us get ahead of an eventual migration anyway.
As would be expected, there are some breaking changes and new conventions that come along with adopting ESM. If you are coming from an existing Greenwood application, you can follow the Upgrade Notes in the release notes and check out some of our links in the Learn More section below. 👇
Below are some great resources to learn a bit more a CJS and ESM in NodeJS that are worth reading. In addition, the Greenwood website and all documentation examples have been written in ESM.