Skip to content
This repository has been archived by the owner on Apr 16, 2020. It is now read-only.

--entry-type=auto #55

Closed
wants to merge 10 commits into from
Closed

--entry-type=auto #55

wants to merge 10 commits into from

Conversation

GeoffreyBooth
Copy link
Member

@GeoffreyBooth GeoffreyBooth commented Mar 9, 2019

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

@GeoffreyBooth GeoffreyBooth added the enhancement New feature or request label Mar 9, 2019
Copy link
Member

@devsnek devsnek left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

- The Zen of Python

prevToken = token;
}
} catch {
return 'commonjs';
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How about this: 4d841b3

src/node_options.cc Outdated Show resolved Hide resolved
Copy link
Member

@ljharb ljharb left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

doc/api/cli.md Outdated Show resolved Hide resolved
lib/internal/errors.js Outdated Show resolved Hide resolved
doc/api/cli.md Outdated Show resolved Hide resolved
lib/internal/modules/esm/default_resolve.js Outdated Show resolved Hide resolved
test/es-module/test-esm-type-auto.js Outdated Show resolved Hide resolved
@ljharb
Copy link
Member

ljharb commented Mar 9, 2019

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
Copy link
Member Author

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
Copy link
Member

ljharb commented Mar 9, 2019

#56

@GeoffreyBooth
Copy link
Member Author

@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?

@nodejs-ci nodejs-ci force-pushed the modules-lkgr branch 3 times, most recently from 9301a06 to e721cd2 Compare March 14, 2019 08:10
@MylesBorins MylesBorins force-pushed the modules-lkgr branch 2 times, most recently from 484d1fb to 7efc53d Compare March 18, 2019 22:07
@nodejs-ci nodejs-ci force-pushed the modules-lkgr branch 3 times, most recently from c7fa700 to d69f765 Compare March 21, 2019 08:06
@MylesBorins MylesBorins force-pushed the modules-lkgr branch 5 times, most recently from 335d584 to 9a343ce Compare March 21, 2019 19:09
@nodejs-ci nodejs-ci force-pushed the modules-lkgr branch 2 times, most recently from 871b78b to 3a00b51 Compare March 23, 2019 08:06
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants