Replace --entry-type with --input-type by GeoffreyBooth · Pull Request #66 · nodejs/ecmascript-modules (original) (raw)

This repository was archived by the owner on Apr 16, 2020. It is now read-only.

Conversation11 Commits1 Checks0 Files changed

Conversation

This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.Learn more about bidirectional Unicode characters

[ Show hidden characters]({{ revealButtonHref }})

Per nodejs/modules#300 (comment), this PR replaces --entry-type with --input-type, a flag just like --entry-type but only for --eval, --print and STDIN.

This way we still provide a way to use ESM in those non-file inputs, but we’re removing the footgun that is --entry-type in its current form. To use ESM in files, the files need to end in .mjs or be in a "type": "module" package scope.

Tests and docs updated.

at this point can we just pr upstream?

Also, I think it is reasonable to work off the fork for changes to the roadmap... So we don't cause upstream noise when we don't have consensus on larger changes...thoughts?

…

What is the solution for extensionless files?

It’s unchanged. As I wrote in nodejs/modules#300 (comment), I’m assuming most people wouldn’t run their extensionless file via node --entry-type=module; for example, you want to just run npm, not node --entry-type=module npm. It defeats the purpose to have a short extensionless filename if you have to run it via a long node command.

So in order to run just npm and for the code of your npm CLI tool to be ESM, npm needs to be a symlink to an .mjs file or a .js file inside a "type": "module" package scope. This is true both under the current --entry-type and this PR. You shouldn’t be putting --entry-type=module in a shebang line because many platforms don’t support that.

Also, I think it is reasonable to work off the fork for changes to the roadmap… So we don’t cause upstream noise when we don’t have consensus on larger changes…thoughts?

👍 We should probably discuss this in the meeting, if people don’t mind. I’m assuming that if this PR gets consensus from our group, I or Myles can open it as a PR upstream. It can’t hurt to get consensus among us first; I feel like our upstream PRs will get accepted more easily if we resolve all our internal disagreements privately first.

I only hope that no one gets confused thinking that this affects process.stdin somehow...

Approved per consensus in 2019-04-10 meeting.

@MylesBorins should I merge this into modules-lkgr or open this as a PR against upstream?