Use .js extension for config/assets.js

[timriley]

If we set "type": "module" in our package.json (opting into ES Module-style JavaScript by default), then we can use an ordinary .js extension for config/assets.js.

This feels much more conventional, less surprising to the casual user.

Opting into ES Modules makes Hanami's default assets setup more future-focused, which I think this is a good posture for us. Getting this detail right now is important, since changing this later will be costly and involve manual user changes.

Those people needing needing legacy CommonJS-style JavaScript can still use it by giving their files the .cjs extension (or even taking away the "type": "module" declaration, and at that point, they likely know what they're doing).

As noted by @KonnorRogers, esbuild can also help with CJS/ESM interop, too.

[jodosha]

@timriley @KonnorRogers I'm annoyed by the .mjs extension as well.

Question: if we force the type: "module" in package.json are we getting in the way of developers that may want/need to declare a different type?

@KonnorRogers, you mentioned a potential conflict with Jest. Anything else that we should be aware of?

---

Are we just embellishing (.mjs -> .js) but creating potential obstacles?

[KonnorRogers]

Nothing else I'm aware of. Most new packages all support ESM. Even newer versions of Jest support ESM.

Question: if we force the type: "module" in package.json are we getting in the way of developers that may want/need to declare a different type?

They can always override if needed. As a whole for new projects, its a pretty benign property. It's mostly legacy projects that have a hard time with it that have outdated dependencies (pretty much anything >4yrs old)

[timriley]

Thanks @KonnorRogers :)

They can always override if needed. As a whole for new projects, it's a pretty benign property. It's mostly legacy projects that have a hard time with it that have outdated dependencies (pretty much anything >4yrs old)

Given this, I'm happy for us to proceed here. People who need to do something different to this will know what they're doing (and in addition, if we find there's sufficient demand, we can make sure this is clear via documentation).