testdouble / scripty Goto Github PK
View Code? Open in Web Editor NEWBecause no one should be shell-scripting inside a JSON file.
License: MIT License
Because no one should be shell-scripting inside a JSON file.
License: MIT License
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.)
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**
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.
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 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:
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
scripty
: 2.1.0
yarn
: 1.22.18
ubuntu 20.04
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
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:
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.
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:
Thanks for scripty. :)
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:
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?
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?
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.