-
Notifications
You must be signed in to change notification settings - Fork 18
Conversation
There was a problem hiding this 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'; |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How about this: 4d841b3
There was a problem hiding this 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.
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 |
bec588f
to
ea59221
Compare
9301a06
to
e721cd2
Compare
484d1fb
to
7efc53d
Compare
c7fa700
to
d69f765
Compare
335d584
to
9a343ce
Compare
871b78b
to
3a00b51
Compare
fd5b55a
to
3a40599
Compare
6fe40a4
to
d9cdfd8
Compare
…ins import or export
…ens approach was too naive
Co-Authored-By: GeoffreyBooth <GeoffreyBooth@users.noreply.github.com>
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
orSTDIN
),--entry-type=auto
tells Node to tokenize the source code to look forimport
orexport
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 firstimport
orexport
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), orvcbuild test
(Windows) passes