Allow directly running using "scripty <target>" about scripty HOT 8 OPEN

What do you think, @jasonkarns?

from scripty.

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.

from scripty.

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)

from scripty.

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:

  scripty/lib/derive-log-level.js

  Line 24 in 75ae875

  return npmLevel[process.env.npm_config_loglevel]

• every option pulled from loadOption can come from npm's environment:

  scripty/cli.js

  Lines 26 to 38 in 00cbfad

  	parallel: loadOption('parallel'),
  	dryRun: loadOption('dryRun'),
  	logLevel: loadOption('logLevel'),
  	quiet: loadOption('quiet'),
  	silent: loadOption('silent'),
  	verbose: loadOption('verbose'),
  	spawn: {
  	stdio: 'inherit'
  	},
  	resolve: {
  	modules: loadOption('modules'),
  	scripts: loadOption('path'),
  	scriptsWin: loadOption('windowsPath')

• 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.

from scripty.

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.

from scripty.

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

from scripty.

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"
}

from scripty.

ooh! I like it!

from scripty.