-
Notifications
You must be signed in to change notification settings - Fork 29.6k
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
watch: watch env files in --watch
mode
#54033
Conversation
observe env files in `--watch` mode through the watcher's filterFile and forward changes to the childProcess Fixes: nodejs#54001
|
||
let kEnv = {}; | ||
for (const arg of process.execArgv) { | ||
if (StringPrototypeStartsWith(arg, '--env-file')) { |
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.
please use getOptionValue
instead of iterating over all of process.execArgv
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 fact, I've already applied getOptionValue
, but when I used getOptionValue('--env-file')
with multiple --env-file options set, I had a problem that I could only get the last --env-file information. Not an array of --env-file information.
const envContent = parseEnv(readFileSync(envFile, 'utf8')); | ||
kEnv = { ...kEnv, ...envContent }; |
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.
const envContent = parseEnv(readFileSync(envFile, 'utf8')); | |
kEnv = { ...kEnv, ...envContent }; |
I am pretty sure that watcher.filterFile
is enough since the spawned process should handle --env-file
by its own
this is also missing error handling (what happens if env file is renamed/deleted)?
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 am pretty sure that
watcher.filterFile
is enough since the spawned process should handle--env-file
by its own
I've tested it many times, but when the child is spwan, it inherits the parent's process.env
. If I only use the watcher.filterFile
, if the env file is modified, it triggers a restart of the child process, but the information from the modified env doesn't seem to go to the child.
This is why I used parseEnv
and readFileSync
.
Refs: #54001 (comment)
this is also missing error handling (what happens if env file is renamed/deleted)?
Oh, this is my mistake.
If I can't find the --env-file I set when I started watch mode (because it's renamed or deleted), is it a good way to print ${envFile}: not found
like when I first start watch mode?
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 PR needs a test
Does this mean I need to write a related test code or does it mean CI workflows in PR? |
You need to write a related test code that covers the feature |
observe env files in
--watch
mode through the watcher'sfilterFile
and forward changes to the childProcessFixes: #54001