Just shared that with the team. I'm hoping I find time this month to make esm work

Started hacking away at this in my

node_modules

folder just seeing if I could force this to happen. I am finding some success swapping the esbuild config in the

NodeHandler

and the

runBeforeBundling

hook with

target: "node14.8",
format: "esm",

I can at least get my project built out properly in that it will properly compile imports on external modules and top level await. Problem now seems to be getting it to run locally, and then I am assuming I would need to add

type: module

in my deployed package.json. Anyway it doesn't feel too far off. I was just curious what your approach was gonna be to this? Seeing that esbuild is bundling all our code there is not much use in ESM imports. The only time they come into play is really external modules (aws-sdk). Since this is transpiled code though I don't think it matters to much whether it is required or imported. However top level await is a bigger deal as we could do async operations prior to a handler even being called. This seems interesting to me. Sadly we need to move to module to get TLA. For local I am wondering if a fake

package.json

in the artifacts folder set to module would get things working, or maybe when using ESM we need to swap to

.mjs

Anyway just thinking out loud as its on my mind. Curious where your head is on this.

you can see what a full conversion to ESM would look like here https://github.com/serverless-stack/serverless-stack/pull/1117

Very interesting, so this would be a full swap to esm across the board not just in the resulting AWS code. I am curious about the

mjs

files. Are there issues going all in on

.js

with package of

type: module

? Could the dynamic requires be swapped with dynamic imports?

I got a full esm setup working a month ago or so but I need to do it again more officially

you thinking all in on ESM? so stack generation and final code is ESM? like could i make my root SST project

type: module

?

I'm hoping that's the case

my dream would be to not have the codegen and to use NodejsFunction

This would be ideal from my perspective away. Though my whole project is TS anyway so I am not sure ESM plays into this to much, I am much more excited for top level await. However the stubborn side of me just would like to know, even after transpile my external deps are loaded with ESM and not cjs/require. Moving everything to esm and projects all having

type: "module"

would be great, and instead of generating

.mjs

files just push out a

package.json

with

type: module

for each lambda. Locally instead of using dynamic

require()

we could just use dynamid

import()

to bring in the handler in dev mode. Or am I missing something obvious?

probably SST would need to be a dual cjs/esm library https://nodejs.org/api/packages.html#dual-commonjses-module-packages I have some experience with that, it's a bit of a nightmare when it comes to things like

__dirname

but there are sort of like polyfills

Yeah thats likely true, so the whole project could be loaded either way. I wonder if it is realistic to keep SST is cjs but export ESM. That might be tough in dev mode though, i think SST might have to support ESM regardless in order to allow for local handlers to be written that way. Another option is to use cjs for dev and esm for builds, but this seems like the opposite of the whole goal of SST.