-
Notifications
You must be signed in to change notification settings - Fork 18
Replace --entry-type with --input-type, plus --input-type=auto #68
Replace --entry-type with --input-type, plus --input-type=auto #68
Conversation
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
64c0a95
to
9dbcc5b
Compare
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.
Repeating my review from #55; If we can’t detect the type unambiguously from syntax, it should throw.
I’m not sure what this means. What are you proposing? The definition of That’s perhaps not the holy grail of unambiguous syntax detection, but as we’ve discussed, unambiguous is impossible. Rather than try to come close and fail some of the time, this redefines the goal: |
f46476e
to
52e8e20
Compare
391215a
to
339ae10
Compare
…ins import or export
…ens approach was too naive
Co-Authored-By: GeoffreyBooth <GeoffreyBooth@users.noreply.github.com>
28e6b9b
to
c0eeba4
Compare
Per 2019-04-10 meeting, I’ll refactor this into a separate PR that creates a new function on Once that’s done and merged in, we can discuss extending its use to other locations such as |
(Let's make sure the API is usable from CJS as well 😄 ) |
Closing in favor of #69 |
#66 plus the addition of
--input-type=auto
. Same logic as #55: if the input string contains animport
orexport
statement, treat it as ESM; otherwise as CommonJS. This is perhaps even more useful for--eval
and--print
.I’m submitting this as a separate PR in case people are okay with #66 but uncomfortable with this addition. You can see the difference between the PRs here:
It’s the same code as from #55, without
-a
.