Esm: Renamed to "esm"

[MajorBreakfast]

Why was this package just renamed to "esm"?

I also see that you've bumped the version to something higher than the existing esm package on npm has. Did you make a deal with the current owner?

Anyhow, the README instructions currently don't work because the package hasn't been published yet :)

[dnalborczyk]

I'm guessing for simplification, mainly to get rid of the scoped package, since it includes only one module.

[dnalborczyk]

I was a little bit surprised myself, but mainly wondering about the implications for existing _std/esm_ and _esm_ users.

_esm_ users might be non-existent, as it was last published looong time ago, and is unmaintained, though has still some downloads (might be just accidental downloads from people trying to install std/esm).

I also wonder how current _std/esm_ users would (or rather could) be notified about such a change? Is there some npm provided mechanism to notify current users, other than deploying v0.25.3 or better _(breaking change)_ v0.26, with an e.g. deprecation notification?

[CacheControl]

Awesome, love the new name! Scopes always feel unwieldy to type (and remember). This will be a bit annoying for existing users in the short term, but _well_ worth it overall.

Since the new version of esm will be 3.0.0, users on the old module will be fine (assuming they have a semver policy protecting them from major versions, and if they don't that's on them).

Agree that a deprecation notice in the old package would be appropriate.

[jdalton]

Hi @MajorBreakfast, @dnalborczyk, and @CacheControl!

What was going to be @std/esm's v1.0 has been in the works for some time. Over the past few months I've been getting things in motion to complete a really nice developer experience. Part of that was acquiring the new, simpler esm name. npm has a process for that which takes a good chunk of time. The previous package was confirmed to be dead. Even still, I'll be sure to handle the transition with i's dotted and t's crossed. Bumping to the next major is part of the process for name transfers.

When I released @std/esm Node was ~6 months out from releasing ESM unflagged in Node. Now, ~7 months later, Node has pushed that back to 9-27months from now, a new Node Module WG was formed (I'm in it), and the roadmap that once was isn't necessarily what will be. Because of that defaulting to "Nodes rules" when those rules haven't been ironed out yet doesn't seem like a good thing. So over the last few months I've been getting things in motion to provide a better developer experience. Here's the plan for vNext.

Developers should be able to pickup ESM today and get coding fast. It should fall right in place with where the ecosystem is TODAY. So that means 💯 percent CJS interoperability (without configuration). Your stuff "just works". If you want to configure things then you can provide options. This allows esm to be a bridge from the ESM of today to the ESM of tomorrow. As Node's path to ESM becomes clear esm will allow developers to step into it.

Here's the usability bit. I want

• node -r esm (will be out in a day or so)
• yarn create esm (will be out in a week or so)
• npm init esm (will be out a bit later)

You all are familiar with node -r esm and the --require bit. So let me explain the other ones.
yarn create esm uses the yarn create command to start a custom project. In this case it will start new esm project with prompts to configure babel or whatever else shakes out. The npm init esm is the npm flavor of yarn create. I'm working with npm to add this feature. So with this you get a very consistent and easy way to start using esm.

Deprecation notices, via npm deprecate and the readme, will certainly be added to @std/esm to let folks know. You should think of the jump to v1 erm v3 as just another minor bump (since in pre 1.0 that's like a major).

[dnalborczyk]

awesome!! thanks for the very informative rundown! looking forward for the things to come!

[MajorBreakfast]

@jdalton Awesome work!

What about "mjs"? Is "mode": "auto" the new default?

[jdalton]

@MajorBreakfast

What about "mjs"? Is "mode": "auto" the new default?

I've aligned naming with webpack, just so there's a thread of consistency being formed.
So now the "js" option is "auto" for unambiguous parsing and "mjs" is now "strict".

The zero configuration scenario will have mode:"auto" and cjs:true (minus top-level return). This aligns with where the ecosystem is today. If you add a config that contains more than just devOpts then you'll need to specify mode and cjs if you don't want them to fall to the strict and false forms.

[MajorBreakfast]

Just to confirm (because it seems strange): You're saying the default values can vary?
No non-dev options, e.g. { cache: false }, leads to { cache: false, mode: 'auto', cjs: true }
But some non-dev options, e.g.{ await: true }, leads to { await: true, mode: 'strict', cjs: false }?

[jdalton]

Ya, I want to avoid having to turn off options...

I could make it so that the default persists unless you specify the cjs object. So mode will be 'auto' unless you specify otherwise and cjs options will be the default unless you specify a cjs options object.

[MajorBreakfast]

@jdalton Yeah, I think that would be better. Having to turn off options is way better than getting unexpected side effects.

[jdalton]

Thanks for helping iron out the details!

Just to be clear here is the intent:

{
  cjs: {
    namedExports: true
  }
}

Will mean that the default of cjs:true (and ~all on) will not be applied. Instead, only namedExports will be enabled for the cjs option. Does that seem reasonable?

[MajorBreakfast]

@jdalton Yep. So, to summarize: cjs defaults to true (almost all enabled) and if an object is specified, all cjs options inside the object default to false => clean slate for power users. I think that works. 👍

[jdalton]

Great!

Here is the next bit. I want to align with webpack in that .mjs is left locked down. If you use .mjs then there is nothing you can unlock. No named exports, no Babel interop, no CJS vars, none of that. This leaves .js and others for interop and .mjs for strict purists. As .mjs evolves we'll unlock as needed (like if it gets support for named exports).

[MajorBreakfast]

Sounds good.

But let's reserve mjs for the purists. I really like that I can continue using js with esm. js is already used for scripts files, webworker files and CommonJS modules. And now es modules. What's one more really? :)