-
-
Notifications
You must be signed in to change notification settings - Fork 5.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[babel 8] Align @babel/node
args parsing to Node.js
#16706
Conversation
import type { PluginAPI, PluginObject } from "@babel/core"; | ||
|
||
const require = createRequire(import.meta.url); | ||
|
||
const program = process.env.BABEL_8_BREAKING |
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.
All the removed lines from this file are just moved to program-setup.ts
process.exitCode = 1; | ||
}); | ||
} else { | ||
const args = [babelNodePath]; |
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.
All this else
block is indented -- review with hidden whitespace diff
@@ -0,0 +1,4 @@ | |||
{ | |||
"BABEL_8_BREAKING": false, | |||
"args": ["foo", "-r", "./dep"] |
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.
This exmaple shows different Babel 7 vs Node.js behavior
Build successful! You can test your changes in the REPL here: https://babeljs.io/repl/build/57863 |
4a907a7
to
b85f359
Compare
Amazing! |
Removing kexec sounds good, I'll open a follow up PR for it. |
8524fe3
to
9c92f3e
Compare
6080ef1
to
38e9fb9
Compare
The problem seems to come from here, but I'm not sure how to fix it elegantly. :) var _nodeFlagsWithValue2 = require("../data/node-flags-with-value.json");
const nodeFlagsWithValue = new Set(_nodeFlagsWithValue2.default); |
Thanks for investigating! I pushed a change that hopefully fixes this. |
4ce39e5
to
cd0ca4f
Compare
@@ -1,4 +1,4 @@ | |||
{ | |||
"args": ["foo", "--extensions", ".bar"], | |||
"args": ["--extensions", ".bar", "foo"], |
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.
If we exit the splitArgs
program args scan without seeing --
, can we scan the userArgs
and make sure there is no match in node flags? If we have seen such match, we can print a warning message such as:
--extensions
seems to be a babel-node/node option. Did you mean babel-node --extensions .bar foo? If you intend to pass --extensions
to your script, please add --
after foo
: babel-node foo -- --extensions. bar
Of course please improve the wordings here. This message should help people during their upgrades from 7 to 8.
If there are multiple matches, we can group the messages and provide one final suggestion.
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.
Will this give rise to false positives? If so I would prefer to keep it as is.
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.
This will indeed give false positive: for example, if you have a script that accepts an --extensions
parameter, it will warn. However, it is easy to suppress the warning (by simply adding --
), so it could be ok?
We could also remove the warning, for example, after that Babel 8 downloads surpass Babel 7 downloads, so that it's only there for the migration period.
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.
That sounds good. :)
cd0ca4f
to
8d92925
Compare
@@ -8,6 +8,7 @@ | |||
"--expose-gc-as=gc2", | |||
"--config-file", | |||
"./config.json", | |||
"--extensions=.js,.ts", |
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.
Do we print warning if there are only node options after the script name? E.g.
babel-node ./foo.js --expose_gc
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.
We do not, because it would require us to keep the v8flags
dependency just for that warning.
However, I'm less worried about that case since when using the Node.js CLI you already have to pass Node-specific options before the script name.
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.
I think it is fine to keep or inline the v8flags
dependency and finally remove it in Babel 9. In Babel 7 the node options after the script name are still passed to node and we align the args parsing only starting from this Babel 8 PR.
For example, I searched babel-node [script name] --max-old-space-size=
, while the majority get the ordering right, there are indeed a few usage where node options are after the script name, because it simply works for Babel 7:
Imagine if they upgrade to Babel 8, their app may stop working due to insufficient memory size. However, it will be a really confusing error: they might keep increasing the --max-old-space-size
until they figure out that --max-old-space-size
after the script name are no longer passed to the node. We could save them lots of time if we just keep v8flags
for a while and remind them to update their usage.
We can also start printing warnings in Babel 7 if node options after the script name is seen, since they will not be supported in Babel 8.
`Run node ./packages/babel-node/scripts/list-node-flags.js --update to update it.` | ||
); | ||
// eslint-disable-next-line n/no-process-exit | ||
process.exit(1); |
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.
Nit: we can just throw Missing flag
as an error so that the process will exit with non-zero code.
1fef072
to
5416d16
Compare
@JLHwung I added the warning for Node.js / V8 options. |
`passing the -- separator before the script name:\n` + | ||
` babel-node ${programArgs.join(" ")} -- ${fileName} ${userArgs.join(" ")}\n` + | ||
` If the intention is to pass ${them} to Babel, move ${them} before the filename:\n` + | ||
` babel-node ${programArgs.join(" ")} ${ambiguousArgs.join(" ")} ${fileName} ${unambiguousArgs.join(" ")}\n`, |
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.
Nit: Can we swap these two? I assume most people are intended to pass options to Babel / Node so let's offer the majority choice first.
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.
Amazing!
This aligns args parsing of
@babel/node
to how Node.js parses arguments:inspect
sub-command--
-e
or-p
flags, there is either-
or a filepathThis means that whether an argument is passed to
process.argv
or not does not depend on its name/value, but simply on its position.To properly parse arguments, we need a list of arguments that take a value, so that we can know that in
babel-node --require foo bar
bar
is the script, while inbabel-node --expose-gc foo bar
foo
is the script. This is auto-generated, our CI will check that it includes all the flags from all the Node.js versions, so that it fails as soon as a new Node.js version is released telling us to add the flag if needed.