[Proposal] Dependencies with command arguments

[vassudanagunta]

Use case

I have build command that takes an optional debug flag that triggers a debug build. It would be very convenient if I could have a script that depends on the debug build without having to create a separate build-debug script, since the only difference is this extra argument:

"run": {
    "command": "node ..."
    "dependencies": ["build"]
},
"debug": {
    "command": "node ..."
    "dependencies": ["build debug"]
}

This dovetails very nicely with how wireit already works, as wireit already

• includes extra arguments in the script fingerprint.
• separately caches and restores invocations with different argument values.

Thus successive, alternating invocations of npm run run and npm run debug is very efficient, only having to restore cached output of build or build debug as needed.

[rictic]

What happens if a script has a transitive dependency on both run and debug? Seems like it's got to be an error. We can detect that at analysis time, and probably deterministically pick a first/nearest script to the tree that depends on both to report the error on.

Do we want to create conditions where it's forbidden for one script to depend upon another? Currently the only other reason it's disallowed for one script to depend upon another is if it creates a cycle in the dependency graph.

[justinfagnani]

I think you could consider flags to be variants of the scripts and that leads to some answers here...

Right now you to do separate prod and debug builds you would need separate commands like build:prod and build:debug. run would depend on build:debug and yes, it would be perfectly fine (from Wireit's point-of-view at least) for a script to depend on run and build:prod. That would simply run both build:prod and build:debug.

Now, maybe that's bad and this could be an opportunity to do better. I think there are only to potentially valid ways to run this differently:

1. Error. If we consider running build in both modes invalid, then expressing them in a way that errors is good. Dependeing on both build and build debug could be an error, where depending on build:prod and build:debug isn't currently.
2. Coalesce the build scripts. I'm not even sure how to do this, but there could be some way to say that scripts do not depend on a flag and can run with any flag value, and maybe they propagate flags. This is sounding more like env variables at this point though.

(1) is certainly simpler to do, and it might not block (2) in the future.

I also think that adding flags has the potential to lead towards a design for macro scripts. If we can define parameters to scripts, we can have other scripts invoke them with arguments - that allows for some conveniences of macros (ie a typescript macro?) and propagating parameters.

[vassudanagunta]

1. Error. If we consider running build in both modes invalid, then expressing them in a way that errors is good. Dependeing on both build and build debug could be an error, where depending on build:prod and build:debug isn't currently.

In other words, the potential for invalid transitive dependencies already exists since script declarations can de facto mutually exclusive / non-idempotent variants (build:prod and build:debug). With parameterized dependencies, what was de facto is now explicit, allowing wireit to catch such errors.

Is my interpretation correct?