Allow directly running using "scripty <target>"

[mkg20001]

Basically I've got a bunch of projects that have scripts like this

scripts/
├── build
│   ├── backend.sh
│   └── frontend.sh
└── start
    ├── backend.sh
    └── frontend.sh

I've only added the top-level commands and would like to run some sub-level commands without adding each target separately to package.json (some projects have way more build scripts than this one)

Would it be possible to add the abbility to run targets directly using scripty <target> for ex npx scripty start:frontend ?

[searls]

What do you think, @jasonkarns?

[jasonkarns]

I'm conflicted. I'm not excited about the idea of having scripty be a cli that is executed directly, since that would add a lot of complexity and either lose or duplicate a lot of the features of npm's run-scripts.

OTOH, the idea for batching up sub-dirs appeals to me. But if tackled, I would probably want to see something closer to #35 and #2, which I think would cover this use case.

[mkg20001]

diff --git a/cli.js b/cli.js
index 088d48f..5b48f5d 100755
--- a/cli.js
+++ b/cli.js
@@ -1,6 +1,7 @@
 #!/usr/bin/env node

-var lifecycleEvent = process.env.npm_lifecycle_event
+var lifecycleFromArgs = Boolean(process.args[2])
+var lifecycleEvent = process.env.npm_lifecycle_event || process.args[2]

 if (!lifecycleEvent) {
   console.error(
@@ -22,7 +23,7 @@ if (!lifecycleEvent) {
   var log = require('./lib/log')

   scripty(lifecycleEvent, {
-    userArgs: process.argv.slice(2),
+    userArgs: process.argv.slice(lifecycleFromArgs ? 3 : 2),
     parallel: loadOption('parallel'),
     dryRun: loadOption('dryRun'),
     logLevel: loadOption('logLevel'),

This is the complicated patch required to make it work ;) (Untested, just some quick idea)

[jasonkarns]

That's not anywhere near an accurate assessment of what would be required to make scripty's CLI usable directly:

• running outside of npm would mean npm's environment won't be available to us
• logLevel is determined through npm's environment: https://github.com/testdouble/scripty/blob/75ae875940f4497dc36e7999f851f31a482a28ba/lib/derive-log-level.js#L24
• every option pulled from loadOption can come from npm's environment: https://github.com/testdouble/scripty/blob/00cbfad0fc66f294712fcce2dd5d513ae58af590/cli.js#L26-L38
• we'd need to add proper help (-h/--help) output
• manpages
• shell completion of scripts and options
• probably other things I'm not thinking about

In short, sure it might be trivial to add just this feature. But making scripty's interface a proper CLI is not a small undertaking. And that's a door that can't be shut once opened.

[mkg20001]

While I understand your concerns, you could use simply use yargs for those tasks. It's not really that complex as it generates a --help view, etc for you

But understandably a lot of effort for little gain.

What could be an interesting feature instead would be to have a command that auto-fills the scripts field.

[jasonkarns]

What could be an interesting feature instead would be to have a command that auto-fills the scripts field.

Indeed! That was actually the very first (and self-opened) issue 😄 #1

[jasonkarns]

Just ran into a use-case where I'd actually like this feature myself.

Now that scripty can run scripts from external packages, I want the ability to rename the script.

Assuming an external package provides script/foo, but within our package, we want it to be run as npm run bar.

We could just invoke the script ourselves, but that can be exceedingly ugly depending on the length of the package name and script (even worse if the external package is scoped).

"scripts": {
  "bar": "node_modules/@user/other/script/foo"
}

It would be nice if we could do:

"scripts": {
  "bar": "scripty foo"
}

On the other hand, I'm curious how ntl might be leveraged with scripty.

Edit: Ha! Overriding npm_lifecycle_eventworks fine for my use-case above:

"scripts": {
  "bar": "npm_lifecycle_event=foo scripty"
}

[searls]

ooh! I like it!