output extension about snowpack HOT 6 CLOSED

@FredKSchott There certainly is the argument of the more directly clear and correct semantics and syntax.
https://v8.dev/features/modules#mjs

Pragmatic stance against them: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Modules#aside_%E2%80%94_.mjs_versus_.js
I disagree with that, I challenge anyone to name a current HTTP server system that doesn’t serve .mjs files with the correct media type.

from snowpack.

The browser doesn't care about file extensions, so this shouldn't have any affect other than cosmetic (if I'm mistaken, lmk!)

I'm not against the idea of providing this as a config option but don't have the time to contribute it myself.

from snowpack.

It's not mandatory but it's recommended by Google Chrome: see here

from snowpack.

Then, the contrary would be better. mjs -> js. Because lots of services doesn't give us access to the config file of the server: the default is .js. In addition, as frontend developers, we don't care about this technical/bad choice from nodejs in browsers.

from snowpack.

Closing since even Node has walked this back a bit (no longer needed for their most recent planned ESM support) and there aren't any benefits that I know of other than ideological. Will keep an eye out in the future though if that changes.

Thanks everyone for the discussion!

from snowpack.

@FredKSchott The Azure Functions environment only respects esm imports if there is a '.mjs' extension. This would be a really useful feature for Snowpack to allow this configuration. Without it, I'm not able to use Snowpack with Azure Functions.

from snowpack.