René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"Feature: ESM in .js files","articleBody":"There needs to be a way to tell Node to treat `.js` files as ESM JavaScript.\r\n\r\nBesides the issue raised in [#149](https://github.com/nodejs/modules/issues/149), there’s the use case of legacy build tools and pipelines that expect only a single file extension for JavaScript. I can give a concrete example for the case of CoffeeScript. The problem is that essentially, the CoffeeScript compiler is a string converter. It takes a string as input, like `console.log 'hello!'`, and returns another string as output: `console.log('hello!');` People who use the CoffeeScript compiler as their entire build chain (as opposed to using it within Gulp or Webpack or the like) use it to transpile projects like this:\r\n\r\n```bash\r\ncoffee --compile --output dist/ src/\r\n```\r\n\r\nThis command recursively searches `src/` for all `*.coffee`, `*.litcoffee` and `*.litcoffee.md` files, runs them through the CoffeeScript compiler, and saves them as `*.js` files in a mirrored folder tree under `dist/`.\r\n\r\nCoffeeScript doesn’t know the parse goals of the files in `src/`. It doesn’t know which ones to save with a `.js` extension versus an `.mjs` extension. About the only way it _could_ know is if we created new file extensions, like `.mcoffee`, `.mlitcoffee` and `.mlitcoffee.md`, that it knew to output as `.mjs`. But that’s not a practical solution, as there are thousands of CoffeeScript build plugins and syntax highlighters and so on out there that would need to be updated to support these new file extensions; and let’s be honest, most of those packages are abandoned. Adding a new option, like `--output-file-extension mjs`, also isn’t realistic for the same reason, because of the sheer number of build plugins that would need to be updated to support it. CoffeeScript traditionally just converts one string into another, without necessarily reading or passing along any other options or metadata, and there are lots of build pipelines that expect this behavior.\r\n\r\nRather than figuring out a way to add a piece of metadata (the parse goal) to CoffeeScript source files, and then updating all other parts of the build chain to preserve and pass along and understand this new metadata, it would be better if the parse goal could be specified outside of the file itself.\r\n\r\nThere’s already one implementation to achieve this: [nodejs/node#18392](https://github.com/nodejs/node/pull/18392), which suggests a `mode` flag for `package.json` files to tell Node to treat `.js` files as ES modules within a given package boundary. There’s also the suggestion [here](https://github.com/GeoffreyBooth/modules/blob/85f0bffde459f82e1603a149d60d2ca7bec4105d/proposals/esm-in-js-files.md#packagejson-section-to-tell-node-how-to-handle-any-file) expand that idea to create a whole new section in `package.json` where users can assign MIME types for file extensions, essentially telling Node how to parse any type of file. Either of these solutions would work.\r\n\r\nWe have the same issue for input that doesn’t come from files, such as from STDIN or via `--eval`. There needs to be some way to tell Node to treat those inputs as ESM, such as a CLI flag:\r\n\r\n```bash\r\nnode --module --eval 'import path from \"path\"; console.log(path.sep);'\r\n```\r\n\r\nThese suggestions are _complements_ for `.mjs`, not replacements. These proposals don’t provide easy ways to keep CommonJS and ESM files side-by-side in the same folder, for example. These are solutions for use cases that go unfulfilled by `.mjs`.\r\n\r\nOne final note: I don’t claim to speak for other compile-to-JavaScript languages, like TypeScript or JSX, but I wouldn’t be surprised if many of them had [similar issues](https://github.com/Microsoft/TypeScript/issues/18442). There are also other categories of build tools and plugins, like linters and minifiers, that may be affected. For maximum compatibility, we should provide multiple ways to signal ESM mode to Node.","author":{"url":"https://github.com/GeoffreyBooth","@type":"Person","name":"GeoffreyBooth"},"datePublished":"2018-07-12T02:04:03.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":14},"url":"https://github.com/151/modules/issues/151"}