Open kriswuollett opened 1 year ago
Also note that MELOS_PACKAGES
environment variable does not have a command line flag, while MELOS_SDK_PATH
has --sdk-path
.
I agree, the current way that packageFilters
works is not intuitive; it's strange that it "triggers" interactivity.
I would prefer for there to be a --select
flag if I want to select packages interactively, instead of having to specify the current --no-select
every time that I want a "regular" non-interactive run.
At the very least, there should be a way to specify --no-select
in melos.yaml
when using packageFilters
(if there is a way to do this, I couldn't find it in the documentation). I'm currently working around this by doing something like this (to avoid typing --no-select
on every run):
scripts:
x:
run: melos run _x --no-select
_x:
exec: ...
packageFilters:
ignore: ...
Really. If you pass --depends-on
as a command line argument to melos exec
, it works without prompting. Why does simply adding it as a config map option force a prompt? Should have a select
option/flag to prompt.
Is there an existing feature request for this?
Command
No response
Description
Replace the interaction suppressing
--no-select
with a option like--filter
. See Turborepo's--filter
for inspiration.Reasoning
I find it inconvenient to have to select a package on which I need to run a script if it uses
packageFilters
. Use cases are generatingbuilt_value
orproto
files in potentially multiple projects. If Melos does have knowledge whether something needs to be rebuilt or not, then it should delegate that responsibility to the command that generates it, i.e., the one of thescripts
.If my package-filtered script was expensive to run and/or isn't smart about rebuilding, then I'd also find it more convenient to specify on which package to run on the command line:
... instead of a user-interaction-required prompt required now:
Requiring a prompt like this may inhibit filtering actions in a CI system, and likely affects its accessibility.
Additional context and comments
The issue was filed since IMO the run behavior with
packageFilters
is incongruent with run without them, while looking at setting something up like this, which I found interesting in that if a script is run in the hook, user interaction is not required and the script is run on all packages:Example run: