Repository navigation
Task runner (node --run) should set lifecycle_event environment variable #52673
Description
What is the problem this feature will solve?
Some npm scripts delegate to another task runner (like Wireit) and require the environment variable npm_lifecycle_event to be set in order to tell which script to run. Yarn and pnpm both set this variable.
The way a Wireit package.json is configured is like this:
{
"scripts": {
"build": "wireit",
},
"wireit": {
"build": {
"command": "tsc"
}
}
}and it's run with npm run build, yarn run build, etc. So Wireit needs npm_lifecycle_event to find the script to run.
Supporting task runner like Wireit would be great because Wireit caches script results, so some invocations don't perform any work after checking the cache and the npm overhead could be noticeable.
Downstream issue: google/wireit#1094
What is the feature you are proposing to solve the problem?
node --run set the npm_lifecycle_event environment variable to the current script.
What alternatives have you considered?
Node could set a different variable and task runners like Wireit could detect that also.
Metadata
Metadata
Assignees
Labels
Type
Projects
- Status
Activity
anonrig commentedon Apr 24, 2024
node task runner is not a replacement for npm. Please take a look at the intentional limitations part in the documentation.
justinfagnani commentedon Apr 24, 2024
This issue isn't asking for a replacement to npm, but a way to know which script was run so that delegated task runners can work.
anonrig commentedon Apr 24, 2024
@justinfagnani The limitations include any npm or other package managers specific environment variables. Your request is to add the npm_lifecycle_event environment variable right? We can introduce "lifecycle_event" environment variable but this won't solve your issue.
justinfagnani commentedon Apr 24, 2024
A
lifecycle_eventvariable would be great. Then task runners could look for that variable too. Right now there appears to be no way to know which script was requested.anonrig commentedon Apr 24, 2024
Makes sense. Looks like a good feature. I've reopened it and will work on it after #52609 lands.
[-]Task runner (node --run) should set npm_lifecycle_event environment variable[/-][+]Task runner (node --run) should set lifecycle_event environment variable[/+]justinfagnani commentedon Apr 24, 2024
Thank you @anonrig!
Looking at the Wireit source code, it looks like it would need an equivalent to
npm_package_json(ie, justpackage_json) as well to identify the package.json file to read configuration from.It also reads additional args, in npm via another env variable, but it might work with the additional args support you've already added (cc @aomarks). I realize there would be an understandable resistance to adding too many environment variables.
aomarks commentedon Apr 25, 2024
Cool! Wireit maintainer here. I'm excited for
node --run, and would love for wireit to support it.What wireit needs to know
package.jsonare we working with?--watchmode? (Wireit has its own watch mode which watches all files across the entire transitive dependency graph of a script, re-executing only each script as needed).Example
npm, pnpm, and yarn all provide this information one way or another. It varies across package managers and across their versions. Here's an example of how it works for npm:
This means "run myscript, with wireit's watch mode enabled, and pass
arg1andarg2down to the process." The way we figure this out is:Read the
npm_config_user_agentenvironment variable. It will be"npm/10.5.1 node/v22.0.0 darwin arm64 workspaces/false"in this example.Read the
npm_package_jsonenvironment variable if set (npm 8 onwards). If it's not set, walk up the filesystem from the CWD until we find apackage.jsonfile. It will be"/path/to/package.json"in this example.Read the
npm_lifecycle_eventenvironment variable. It will be"myscript"in this example.Read the
npm_config_watchenvironment variable. It will be"true"in this example.Read
argv.slice(2). It will be["arg1", "arg2"]in this example.The relevant code is at https://github.com/google/wireit/blob/main/src/cli-options.ts
Suggestions
My thoughts about how this all affects
node --run:npm_lifecycle_eventI agree with the assessment above that setting
npm_lifecycle_eventor equivalent is the most important thing. That would unlock most of the functionality of wireit.I would gently encourage actually just using the
npm_lifecycle_eventname instead oflifecycle_event, because it has sort of become a defacto standard, despite thenpm_prefix. npm, pnpm, yarn, wireit itself, and probably other runners all setnpm_lifecycle_event. Another name is also fine, though, since we can just add special support for it in wireit.npm_config_user_agentThe
npm_config_user_agentenvironment variable would be very nice to set, since that would give us a clear signal of which runner we're dealing with, so that we can then interpret all the other environment data correctly. npm, pnpm, and yarn all setnpm_config_user_agenttoday, so it would be nice to follow that defacto standard.npm_package_jsonThe
npm_package_jsonenvironment variable would be nice, but its only benefit for wireit would be a slight performance optimization, since we can always just look at the filesystem if it's not set.--watchflagWireit has its own watch mode, which is enabled by setting the
--watchflag. It's also likely we'll add more wireit flags in the future, things like--cleanto bust the cache, or--verbosefor more debugging info.The way this works with npm is that any argument after
npm run myscriptbut before--is converted into the environment variablenpm_config_<name>. I concede this is a bit odd, since it means something likenpm run myscript --typomeans the--typoflag is silently ignored. It does enable some useful functionality though, since it lets us distinguish runner flags from script flags.Currently,
node --runinterprets all arguments before the--as being arguments to node itself, so something likenode --run myscript --watch -- arg1 arg2errors.We can't really use
node --run myscript -- --watch arg1 arg2as the syntax, because then we can't distinguish between arguments for wireit vs arguments for underlying script process.I think the only syntax that would currently work is
node --run myscript -- --watch -- arg1 arg2.I'm not sure what I'd suggest here -- allowing delegated runner arguments would be really nice, and would match the behavior of npm/pnpm/yarn, but it does have that downside of invalid arguments getting ignored in some cases.
anonrig commentedon May 17, 2024
@aomarks Thank you for the response. Sorry I couldn't respond in a timely manner, but I've opened a PR to add
NODE_LIFECYCLE_EVENTenvironment variable: #530321 remaining item
anonrig commentedon May 19, 2024
@aomarks I've opened one more pull-request to add
NODE_RUN_PACKAGE_JSON_PATH#53058 tonode --runUnfortunately, I don't think we should add a
user_agentkind environment variable. I think it's unnecessary at this point.NODE_RUN_SCRIPT_NAMEis only available whennode --runis executed, and you can use the existence of that to validate if it'snode --runthat runs the context.I didn't quite understand the
--watchflag argument. Do you want to get access to any cli arguments passed after the script name and before the--? For example, for the following commandnode --run test --my-flag -- --help, do you want to know--my-flagin an environment variable?aomarks commentedon May 20, 2024
Awesome!
👍
Yes, exactly.
cli: add `NODE_RUN_SCRIPT_NAME` env to `node --run`
cli: add `NODE_RUN_PACKAGE_JSON_PATH` env
cli: add `NODE_RUN_PACKAGE_JSON_PATH` env
cli: add `NODE_RUN_SCRIPT_NAME` env to `node --run`
cli: add `NODE_RUN_PACKAGE_JSON_PATH` env
Support node --run (#1169)
github-actions commentedon Nov 17, 2024
There has been no activity on this feature request for 5 months. To help maintain relevant open issues, please add the never-staleIssues and PRs exempt from automated stale handling.
label or close this issue if it should be closed. If not, the issue will be automatically closed 6 months after the last non-automated comment.
For more information on how the project manages feature requests, please consult the feature request management document.
github-actions commentedon Dec 17, 2024
There has been no activity on this feature request and it is being closed. If you feel closing this issue is not the right thing to do, please leave a comment.
For more information on how the project manages feature requests, please consult the feature request management document.