Repository navigation
Task runner (node --run) should set lifecycle_event environment variable #52673
Description
Activity
node task runner is not a replacement for npm. Please take a look at the intentional limitations part in the documentation.
Reacted by mdh and mark-dropbearnode task runner is not a replacement for npm. Please take a look at the intentional limitations part in the documentation.
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.
Reacted by mdh and mark-dropbear@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.
Reacted by mdh and mark-dropbearA
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.Reacted by Yagiz Nizipli, Augustine Kim, Al Marks, Elliott Marquez, mdh, Danny Blue and mark-dropbear- changed the title
[-]Task runner (node --run) should set npm_lifecycle_event environment variable[/-][+]Task runner (node --run) should set lifecycle_event environment variable[/+]on 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.
Cool! Wireit maintainer here. I'm excited for
node --run, and would love for wireit to support it.What wireit needs to know
- Which script runner are we using (npm, node --run, pnpm, yarn)? So that we know where to look for the next 4 items.
- Which
package.jsonare we working with? - Which script is running?
- Should we run in
--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). - Which additional arguments should we pass down to the process?
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:
npm run myscript --watch -- arg1 arg2
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.
Reacted by mdh and mark-dropbear1 remaining item
@aomarks I've opened one more pull-request to add
NODE_RUN_PACKAGE_JSON_PATH#53058 tonode --runnpm_config_user_agent
Unfortunately, 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.--watch
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 I've opened one more pull-request to add
NODE_RUN_PACKAGE_JSON_PATH#53058 tonode --runAwesome!
npm_config_user_agent
Unfortunately, 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.👍
--watch
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?Yes, exactly.
- added a commit that references this issue
on May 21, 2024 - added a commit that references this issue
on May 21, 2024 - added a commit that references this issue
on Jun 1, 2024 - added 2 commits that reference this issue
on Jun 20, 2024 There has been no activity on this feature request for 5 months. To help maintain relevant open issues, please add the never-stale
Issues 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.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.
Reacted by Toni Villena
Metadata
Metadata
Assignees
Labels
Type
Projects
- Status
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_eventto 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 needsnpm_lifecycle_eventto 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
npmoverhead could be noticeable.Downstream issue: google/wireit#1094
What is the feature you are proposing to solve the problem?
node --runset thenpm_lifecycle_eventenvironment 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.