I'm intrigued! But for me to be able to use it I would have to specify another folder name and/or path where scripty would look for scripts. Would that make sense?

./scripts/* => ./core/scripts/* etc... I don't want to add another namespace infront of the scripts names core:dev:app

Opening and claiming this issue myself.

Appears that nodenv init is getting executed during scripty's invocation, as nodenv is prepending itself to PATH a second time within the context of a scripty script.

I have below package.json file

{
  "name": "scripty-issue",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1",
    "dev": "node app.js",
    "foo": "scripty"
  },
  "keywords": [],
  "author": "",
  "license": "ISC",
  "dependencies": {
    "cross-spawn": "^7.0.3",
    "express": "^4.17.1"
  },
  "devDependencies": {
    "scripty": "^2.0.0"
  },
  "scripty": {
    "logLevel": "verbose"
  }
}

and below is '/scripts/foo.sh'

echo "Hello";

When I run
npm run foo getting below error on windows.

internal/child_process.js:366
    throw errnoException(err, 'spawn');
    ^

Error: spawn UNKNOWN
    at ChildProcess.spawn (internal/child_process.js:366:11)
    at spawn (child_process.js:551:9)
    at module.exports (D:\Explore\scripty-issue\node_modules\scripty\lib\run\spawn-script.js:8:17)
    at cb (D:\Explore\scripty-issue\node_modules\scripty\lib\run\index.js:4:27)
    at D:\Explore\scripty-issue\node_modules\async\dist\async.js:3880:24
    at replenish (D:\Explore\scripty-issue\node_modules\async\dist\async.js:1011:17)
    at D:\Explore\scripty-issue\node_modules\async\dist\async.js:1016:9
    at eachOfLimit (D:\Explore\scripty-issue\node_modules\async\dist\async.js:1041:24)
    at D:\Explore\scripty-issue\node_modules\async\dist\async.js:1046:16
    at _parallel (D:\Explore\scripty-issue\node_modules\async\dist\async.js:3879:5)

Just works fine on ubuntu. Any pointers would be helpful. I tried passing {shell:true} in node_modules\scripty\lib\run\spawn-script.js:8:17 and it just worked fine.

For discoverability, developers expect available scripts to be listed from npm run. It appeared to me that scripty scripts are not - is that expected behavior?

Dean

Just that, my coworker is working on some complex scripts that work during preinstall, how well would scripty do there?

I imagine it has to be installed as a global in that case?

Hello, awesome project.
I am evaluating this package to convert the scripts of a big project.
The problem is that the separation char used is -.

Currently the separation char is hardcoded do you think it's possible to have a way to change this? With a package.json scripty key or something.

For the most part scripty works just fine with pnpm, the only difference I've run into is the forwarding of command-line arguments does not work.

I suspect this is because with npm you have to explicitly use the -- to forward arguments, and with pnpm you do not.

I can submit a PR if you can point me in the right direction @jasonkarns - it wasn't obvious to me which part of the codebase I'd need to make a change in to support this 🤓

When using [email protected] and [email protected], Scripty is not finding custom script paths when run through Yarn. I tested this using the config example given in the docs for using a custom directory.

When introducing scripts into these directories and adding them to the package.json file, Scripty fails to find them and prints an error that indicates it was not even attempting to read those directories.

As an alternative to having to chmod +x scripts, users could add an option:

"scripty": {
  "runWith": "bash"
}

The only changes needed would be to add a branch in spawn-script like spawn(options.runWith, [scriptFile].concat(userArgs), options.spawn) and bypass the isExecutable check.

All my scripty usages have silent mode on, but I dislike needing the configuration block for every one.

Per the unix guidelines, I think scripty should be silent by default, and instead have a verbose flag. (Dry run mode should probably then imply verbose.)

Description

The async dependency has a vulnerability in the current version of the project, which has been resolved as of version 2.6.4.

Vulnerability: **🔴high** [Prototype Pollution in async.](https://www.npmjs.com/advisories/1070440)
Dependency: **async**

Risk

Could allow a malicious user to gain privileges through the mapValues() method.

Hi,

If we have this folder structure:

scripts/
    build/
        client/
            sass.sh
            tsc.sh

Running npm run build will not search recursively inside child folders and so will not run npm run build:client. Is it a wanted comportment?
In my mind, running npm run stuff would run all subtasks, even with more than 1 :.

One idea to avoid explicit parent scripts that only care about ordering is to override undefined glob-order with whatever ordering is in the package.json for a set of child scripts.

I like the idea of this project, and I had even began writing something similar.

A common thread through several issues is "options". One needs to be able to have greater control over scripty's behavior. See #28 for an example.

If using the config prop of package.json is problematic, perhaps a .scriptyrc is warranted?

Anyway, I think there hasn't been a decision made on this strategy, so here's an issue for discussion.

Hello,

because of RFC21 : https://github.com/npm/rfcs/blob/latest/implemented/0021-reduce-lifecycle-script-environment.md

npm_package_* are no longer exported in the environment variables

No idea what the fix should be

Thanks for the hard and awesome work on this!

Since npm/npm#3494, if I want to pass args to the script run by npm run (as distinct from passing args to npm), I pass them after a --.

npm run test -- --grep 'specific test' #<- these are args for mocha, not for npm

GitHub's ScriptsToRuleThemAll is picking up steam as a conventional way of having scripts in a standard location across different language stacks. They use script/ as their conventional directory.

And anecdotally, a lot of nix devs I know seem to default to putting their shell scripts in script/ as well.

I don't know if script/ is some long standing convention of sysadmins or a recent conventional, but it's seemingly more common than scripts/ as a directory.

I know that the script directory can be configured manually, but convention would be better. And since script/ is the same as scripts/ in spirit ;), I propose we also allow script/ to be used by default, without the manual configuration. Implementation would just use script/ as a fallback. (Or perhaps prefer script/?) I think odds of repos having both script/ and scripts/ is virtually nil, so I don't foresee any issue with accepting either.

I'd also support migrating towards script/ as a default, and doing away with scripts/ at some point in the future. But supporting both for a while would allow for backwards compatibility.

Scenario

If I have my package.json like so:

"scripts": {
    "server:a": "scripty",
    "server:b": "scripty",
    "server": "scripty"
}

and my scripts:

.
|scripts-win/
-|server/
--|a.cmd
--|b.cmd

where both a.cmd and b.cmd always need to run in parallel.

The issue

The documentation says I should be able to change my package.json node to:

"server": "SCRIPTY_PARALLEL=true scripty"

which obviously won't work on Windows. I tried changing it to:

"server": "set 'SCRIPTY_PARALLEL=true' && scripty"

but that runs them in series.

What's the recommended way of forcing tasks to run in parallel on Windows?

Please let me know if that's not clear or needs more information.

Loving this lib, finding it extremely useful in our project. As we accrue more and more scripts, we're finding that most scripts share some basic startup/shutdown behaviors, which (in line with the seeming intent of this lib) might be better served as some sort of lifecycle hooks rather than repeated boilerplate. As a trivial example, a big team might be interested in displaying a warning if a project's npm modules aren't up-to-date before running any script.

Following the convention-over-configuration style found here, scripty could look for ./scripts/hooks/before and ./scripts/hooks/after.

This seems appropriate to add to the lib to me, but I could also understand an argument that this is strictly a userland concern. Thoughts?

I set scripty.path in package.json file but it's not work. Here are my env information:

• scripty version: 2.0.0
• npm version: 8.1.0
• node version: 16.13.0

I'd like to read more how scripty can solve the problems of using npm as a build tool.
Here's a good article I think which describes some common problems: https://medium.com/@leo/should-npm-really-be-used-as-a-built-tool-e8ff4f6cbcef
Can scripty help with that? If yes, how? I'd love to read a blog post or something based on real experience.
Thanks!

I previously had prebuild: yarn test but I need to avoid {pre,post}* hooks. My new build script is:

#!/bin/bash
set -eu
runner=${npm_config_user_agent%%/*} # npm or yarn
$runner run test                    # or scripty test
parcel build src/index.html

Is there a simpler way to do what I want? Ideally I'd rather write scripty test and be done with it. Do you see any reason it wouldn't make sense to allow the lifecycle event to be overriden in a child script? Or better to consider #35 (ordered scripts) or #43 (set runner in a before hook)?

ATM I have some unit tests structured as such:

    "test": "scripty",
    "test:clean": "scripty",
    "test:knexreset": "scripty",
    "test:unit": "scripty",
    "test:integration": "scripty",
    "test:integration:installation": "scripty",
    "test:integration:manager": "scripty",

The contents of the files:

## /scripts/test/index
#!/usr/bin/env sh

npm run test:unit
npm run test:integration

## /scripts/test/unit
#!/usr/bin/env sh

# run some test commands

## /scripts/test/integration/installation
#!/usr/bin/env sh

# run some test commands

## /scripts/test/integration/manager
#!/usr/bin/env sh

# run some test commands

The problem I'm having is that when I run npm test, when one of those subscripts fails it doesn't exit with a non-zero code, so the continuous integration thinks that the tests passed.

What is a way to fix this?

For the moment I'm just running npm run test:unit && npm run test:integration:manager && npm run test:integration manually, so that each one does produce a proper error code on exit and the tests fail if one of them fails.

Scripty is kind of, well, magic. Meaning if you are unfamiliar with Scripty, and see something like this:

{
  "scripts": {
    "bump": "scripty",
    "bump:major": "scripty",
    "bump:minor": "scripty",
    "bump:patch": "scripty",
    "update": "scripty",
    "preversion": "scripty",
    "publish-please": "scripty",
    "test": "scripty",
    "test:browser": "scripty",
    "test:browser:dev": "scripty",
    "test:lint": "scripty",
    "test:node": "scripty",
    "test:nsp": "scripty"
  }
}

...you're not going to know what the hell is going on.

What can be done about this?

Does this module allow me to use the .sh file extension? If not is there a reason?

I imagine this is not intentional as it ignores to log level completely.
Possible source of the issue: https://github.com/testdouble/scripty/blob/master/lib/run/spawn-script.js#L6

Version Tested: 1.9.1

• Versions:
  • scripty: 2.1.0
  • yarn: 1.22.18
  • OS: ubuntu 20.04

Actual Behavior

scripty can't find my scripts inside my helper module.

~/projects/my-project
❯ yarn lint
yarn run v1.22.18
$ scripty
scripty ERR! No script found for npm lifecycle 'lint' matching any of:
scripty ERR!   /home/taschetto/projects/my-project/script/lint+(|.*)
scripty ERR!   /home/taschetto/projects/my-project/script/lint/index+(|.*)
scripty ERR!   /home/taschetto/projects/my-project/script/lint/*
scripty ERR!   /home/taschetto/projects/my-project/node_modules/scripty/scripts/lint+(|.*)
scripty ERR!   /home/taschetto/projects/my-project/node_modules/scripty/scripts/lint/index+(|.*)
scripty ERR!   /home/taschetto/projects/my-project/node_modules/scripty/scripts/lint/*
scripty ERR! Either define a script or remove "scripty" from 'scripts.lint' in your package.json.
error Command failed with exit code 1.

Even though...

~/projects/my-projects
❯ ls -la ./node_modules/@my-org/node-scripts/scripts/lint 
total 16
drwxrwxr-x 2 taschetto taschetto 4096 jun 10 16:58 .
drwxrwxr-x 5 taschetto taschetto 4096 jun 10 16:58 ..
-rwxr-xr-x 1 taschetto taschetto   40 jun 10 16:58 fix
-rwxr-xr-x 1 taschetto taschetto  118 jun 10 16:58 index

Expected Behavior

The script should have been found.

my-projects/package.json

{
  // redacted
  "scripts": {
    "lint": "scripty",
  },
  // redacted
  "devDependencies": {
    "@my-org/node-scripts": "1.0.1",
    "scripty": "^2.1.0"
  },
  "config": {
    "scripty": {
      "modules": ["@my-org/node-scripts"]
    }
  }
}

Idea being: by inspecting the file system of scripts/, you should be able to populate the "scripts" section of the package.json so folks don't have to manually keep package.json in sync manually.

On the other hand we could seek a more dynamic approach that'd allow scripty to intercept npm run without ever changing the package.json

For now i think the right thing to do is be explicit like we are being until we get some usage as feedback

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 ?

Is there a way to easily share scripty scripts via a npm package?

We have a need to share a set of common scripts with some internal teams and we could like to do that via a normal npm package.

You can think of a workflow like:

yarn add common-scripts

This package will contain binaries that are exported to either node_modules/.bin or have them defined in node_modules/common-scripts/scripts. Then the teams can simply defined there command to look like:

{
  "scripts": {
    "build": "scripty"
  }
}

And of course run it like normal:

yarn build

Currently we modify the scripty property in package.json to hack this together:

"scripty": {
  "path": "node_modules/common-scripts/scripts"
}

This has a couple of problems:

1. Can only reference one package (you could see a world where we might want to have multiple npm packages that teams install that separate the scripts by some kind of domain seperation)
2. If you change the path you cannot have "local" scripts that override external ones. Teams should be able to define a local executable that will override an external one.

Some potential ideas would be to have scripty look into node_modules/.bin if it cant find an executable that is already defined in ./scripts. Another one would be to make path an array. I would like to hear your thoughts on this and if this sounds alright I can help implement the change if need be.

cc: @stefanpenner

https://npm.community/t/allow-another-module-to-manage-scripts/6337

Just creating an issue here to track the status of the proposal

"scripty": {
  "path": "../core/scripts"
}

This doesn't work anymore with scripty v1.7.0.
In version v1.6.* it is working.

Edit:
It is simply ignoring the custom path and only searches for the default ones

I had previously given no thought to what to do when the $npm_lifecycle_event var isn't provided.

1. When no CLI args are passed, bomb out as unsupported and print usage instructions
2. When scripty is run like scripty test:unit assume that first arg is the lifecycle event name (is this a good idea? Might be risky to encourage people to run scripts outside the contextof all those npm environment tweaks)

Hi:

1. Thanks for scripty. :)

2. Can there be a hierarchy of script choices? I want to distribute scripts to utilize by downstream consumers in an npm module, but I also want to be able override some of those scripts in my app.

package.json fragment:

"scripty": {
  "path": [
    "../../scripts",
    "tools/scripty-scripts"
  ]
},

tools/* will get bundled into an npm package and distributed but I want some 'private' overrides at the ../../scripts level.

Continued from Twitter.

scripty subsumes some of the functionality of npm-run-all with stronger conventions and separation of concerns. The only feature I see missing is optional parallel execution of subtasks although I have no immediate use case.

Contents of scripts:

scripts/
├── bump
│   ├── index.sh
│   ├── major.sh
│   ├── minor.sh
│   └── patch.sh
├── preversion.sh
├── publish-please.sh
├── test
│   ├── browser
│   │   ├── dev.sh
│   │   └── index.sh
│   ├── index.sh
│   ├── lint.sh
│   ├── node.sh
│   └── nsp.sh
└── update.sh

test/index.sh invokes npm run test:lint && npm run test:nsp && npm run test:node && npm run test:browser. test/browser/index.sh invokes karma.

scripty erroneously executes test/browser/dev.sh. at least.. I think that's in error.

We're using scripty for our npm start script, under supervisord, in all environments. The supervisor is having difficulty shutting down the server, as it appears only scripty receives the signal (for one reason or another, we're not sure if it's configured for SIGHUP or SIGTERM at the moment).

I can think of two reasonable solutions:

1. Propagate signals through scripty to the managed process tree.
2. Add to the documentation a recommendation against using scripty for npm start, under supervisors (e.g. supervisord, upstart), or both.

I'd like to suppress the echoing of the script file.

What if:

{
  "scripts": {
    "scripty": "scripty"
  }
}

$ npm run scripty my:script

???

Part of the beauty of npm scripts is that you can run npm run and see a list of all the scripts and the commands they run. No digging to find what a command does.

Is there a way to get a similar list of commands like npm run?

Is it possible to write all scripts in one file? I'm loving the idea of getting my scripts separated from the package.json config, having syntax highlighting and not having to quote-escape them, but I'm afraid that having all my scripts in separated files will make it too separated and hard to maintain.

Could I for example write a scripts/index file, like a explicit parent script, that also receives the script path that is being executed? Then I could write a switch statement to handle all scripts.

You removed builtIn scripts in 17520b5. It'd be useful in my project to expose base scripts that dependent packages can override (I'll summarize better when it's not so late). It would only require changing 1) builtIn scripts to be resolved relative to node_modules and 2) add an option named something like preset.

Is it possible that using scripty over a raw npm script would affect performance negatively? I'm seeing a ~10% performance hit and the only thing I'm changing is whether I'm using scripty or not. Sorry I don't have any solid data/benchmarks for this 😕

Is it possible to have a custom path for certain scripts? I'm thinking via an environment variable or something. The use case is to have a shared scripts module, but also custom scripts for a project. An example package.json:

  "scripts": {
    "test": "scripty",
    "start": "scripty",
    "shared-script": "CUSTOM_SCRIPTY_PATH=./node_modules/shared-scripts/scripts scripty",
    "another-shared-script": "CUSTOM_SCRIPTY_PATH=./node_modules/shared-scripts/scripts scripty"
  },

It'd be nice, to do:

$ SCRIPTY_DRY_RUN=1 npm run test

And have Scripty print out the location and contents of the scripts that would be invoked without actually executing them.

Build #worksforme. I suspect issues on travis are linux or pathname related.

Is there a way to start powershell scripts on Windows?

• scripts
  • lint
  • css
  • js
    • index
    • check

Expected: yarn lint runs lint/css and lint/js/index.

Actual: yarn lint only runs lint/css because it's non-recursive on directories.

Working on a PR.

Hello, thanks for the library.

We are currently using it in a monorepo to ensure that the same script is run in all packages.

The one thing I would like to improve is to have a single point of configuration within the monorepo. To be more specific, we have the following configuration in every single package.json:

"config": {
  "scripty": {
    "path": "../../scripts",
  }
}

A quite straight forward solution that comes to my mind is to use cosmiconfig that could easily find e.g. .scriptyrc.js in root of the monorepo in order to load the configuration. I think it might be a pretty simple PR.

What do you think? Is it a viable option? Or is there a workaround I haven't found?