--entry-type=auto

[GeoffreyBooth]

This implements --entry-type=auto per the entry points proposal.

For potentially ambiguous initial entry points (.js or extensionless files in a package scope with no "type" field, string input via --eval or --print or STDIN), --entry-type=auto tells Node to tokenize the source code to look for import or export statements. If any are found, the initial entry point is treated as if the user had specified --entry-type=module; otherwise like --entry-type=commonjs.

I’m using the Acorn tokenizer because its full parser lacks support for import() expressions. The tokenizer is also faster, and can exit early as soon as the first import or export statement is found. Acorn is already a part of the Node codebase, and I’m not loading it unless --entry-type=auto is specified.

Checklist

• make -j4 test (UNIX), or vcbuild test (Windows) passes
• tests and/or benchmarks are included
• documentation is changed or added
• commit message follows commit guidelines

[devsnek]

"In the face of ambiguity, refuse the temptation to guess."

- The Zen of Python

[devsnek]

garbage in shouldn't be 'commonjs' out. this should be an error saying node couldn't guess the parse goal.

[GeoffreyBooth]

So if this catch ever gets reached, it’s because the tokenizer fails to parse the syntax. I read the source code for Acorn’s tokenizer and as far as I can tell, the only exceptions it throws are for unterminated strings and template literals.

I can throw an error here, but it would be pretty generic, something like “Could not parse input source code.” Whereas if I let Node parse and evaluate the code, it would give a specific error with the line number and details of the syntax error. Either way the user is getting an error message; but if we allow this to hand off to the CommonJS loader, the user gets a better error.

[GeoffreyBooth]

How about this: 4d841b3

[ljharb]

Concur with @devsnek’s review here. If we can’t detect the type unambiguously from syntax, it should throw.

What happens if i specify -a along with --type=module, or -a along with -type of any value? I’d expect an error.

[ljharb]

Repeating so it doesn't get lost: What happens if i specify -a along with --type=module, or -a along with -type of any value? I’d expect an error.

[GeoffreyBooth]

Repeating so it doesn’t get lost: What happens if i specify -a along with –type=module, or -a along with -type of any value? I’d expect an error.

I would too. This is actually a bug in the implementation in general right now, not specific to this PR; you can pass -m and --type=commonjs together, or --type=module and --type=commonjs together, and no error is thrown. Do you mind opening an issue?

[ljharb]

#56

[GeoffreyBooth]

@ljharb and @devsnek I think I’ve addressed all your notes, aside from -a. Is there anything else?

I can split off -a into a separate PR. That way, this can land without it and then -a can be debated separately. Would that be acceptable?