Comments (7)
A lifecycle_event
variable 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.
from node.
Makes sense. Looks like a good feature. I've reopened it and will work on it after #52609 lands.
from node.
node task runner is not a replacement for npm. Please take a look at the intentional limitations part in the documentation.
from node.
node 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.
from node.
@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.
from node.
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.json
are we working with? - Which script is running?
- Should we run in
--watch
mode? (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 arg1
and arg2
down to the process." The way we figure this out is:
-
Read the
npm_config_user_agent
environment variable. It will be"npm/10.5.1 node/v22.0.0 darwin arm64 workspaces/false"
in this example. -
Read the
npm_package_json
environment variable if set (npm 8 onwards). If it's not set, walk up the filesystem from the CWD until we find apackage.json
file. It will be"/path/to/package.json"
in this example. -
Read the
npm_lifecycle_event
environment variable. It will be"myscript"
in this example. -
Read the
npm_config_watch
environment 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_event
I agree with the assessment above that setting npm_lifecycle_event
or 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_event
name instead of lifecycle_event
, because it has sort of become a defacto standard, despite the npm_
prefix. npm, pnpm, yarn, wireit itself, and probably other runners all set npm_lifecycle_event
. Another name is also fine, though, since we can just add special support for it in wireit.
npm_config_user_agent
The npm_config_user_agent
environment 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 set npm_config_user_agent
today, so it would be nice to follow that defacto standard.
npm_package_json
The npm_package_json
environment 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.
--watch
flag
Wireit has its own watch mode, which is enabled by setting the --watch
flag. It's also likely we'll add more wireit flags in the future, things like --clean
to bust the cache, or --verbose
for more debugging info.
The way this works with npm is that any argument after npm run myscript
but before --
is converted into the environment variable npm_config_<name>
. I concede this is a bit odd, since it means something like npm run myscript --typo
means the --typo
flag is silently ignored. It does enable some useful functionality though, since it lets us distinguish runner flags from script flags.
Currently, node --run
interprets all arguments before the --
as being arguments to node itself, so something like node --run myscript --watch -- arg1 arg2
errors.
We can't really use node --run myscript -- --watch arg1 arg2
as 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.
from node.
Thank you @anonrig!
Looking at the Wireit source code, it looks like it would need an equivalent to npm_package_json
(ie, just package_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.
from node.
Related Issues (20)
- v22.0.0 breaks --v8-lite-mode build missing action for js-to-wasm-tq-csa.cc HOT 2
- Is `vcbuild` really needed
- `vm`: `constants` is undefined HOT 4
- Allow bailing early when test fails HOT 8
- Inconsistent presence of property in contextified object HOT 3
- Watch does not debounce restart when different files are updated within the debounce period
- gyp ERR! stack RangeError: Maximum call stack size exceeded HOT 8
- Could we support `corepack enable --yes`?
- `Reflect.has` triggers getters on global object contextified by `vm` HOT 3
- node --run doesn't split additional params HOT 3
- feat(doc): Add warning blocks to API docs
- Mybots
- npm not installing along with node 22.0.0. HOT 2
- fs.glob add option to only include files (not directories) in the results entries HOT 4
- Re-enable test-ubsan.yml
- Compiler error running on Node 20.12 (works in 20.11.6) in napi-intl.h when calling napi_status napi_create_external_buffer HOT 2
- The different of process.next() between MacOS and Linux
- Define node::StreamBase's "onread" property as a JavaScript accessor
- comments in .env files are parsed as values HOT 3
- test runner runs beforeEach or test case before "before hook" finished HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from node.