Feature Request : Add an option to skip script not found error

[jpolo]

Hi,

I am struggling with a problem when using wildcards ex: 'myscript:*'. At the moment if no script starting with myscript is found it throws an error.

The only workaround I found was to create an empty script but it is kind of hacky, and it creates noise in the package.json.

It would be nice to add an option to the cli to be able to ignore this kind of error.

Thanks in advance !

[bcomnes]

Can you explain the use case further? Why do you have wildcards with no subscripts?

[voxpelli]

Essentially a if-present for npm-run-all2 then.

I myself have used --if-present for npm run in reusable GitHub Action workflows to enable automatically running eg build steps when build scripts are present.

If I instead of npm run would do npx npm-run-all2, then I could see the need, but I instead always do a foo for a foo:*, so that I can define in foo if it should be a run-p foo:* or run-s foo:* or even a run-s bar foo:* (eg. run-s clean build:* is a classic for me)

[bcomnes]

Possibly open to the feature, but I don't have any interest in implementing it.

[jpolo]

Can you explain the use case further? Why do you have wildcards with no subscripts?

Most of my projects are standardized / based on generators. When I generate the empty package, I generate a package.json script for all common tasks. for example "lint": "run-p 'lint:*'" (and for many tasks : lint, test, build, etc)

This is helpful and safe because I only have to add new lines when adding a new tool, I do not have to modify any line (open / close principle)

To sum up here are the cases when I have a wildcard considered as a success :

• When I generate the new package, the CI should pass
• For some cases such as shared configurations, some tasks are irrelevant (ex: test for a typescript configuration). Still I would like to keep my package.json standardized.

[bcomnes]

What if we just change the default behavior? (similar to mapping over an empty array) Would that break anything?

[jpolo]

So you mean that if the default behavior of the command would be : if no script is found the script shall exit with a 0 code ?

For me, it would be great, I do not know for other use cases of other apps.

Personally, I find this default behavior much more logic...

[bcomnes]

I recently read "A Philosophy of Software Design" by John Ousterhout and have been mulling on some of the ideas in the book including:

Throwing exceptions is easy; handling them is hard. Thus, the complexity of exceptions comes from the exception handling code. The best way to reduce the complexity damage caused by exception handling is to reduce the number of places where exceptions have to be handled. The rest of this chapter will discuss four techniques for reducing the number of exception handlers.

A great chapter, and generally compelling argument in reducing errors when they can just be avoided.

I think handling empty run globs similar to empty array methods is probably an acceptable way to go. True, if you change your glob string on accident, and now your sub-scripts don't get run, it won't throw an error, but thats likely to manifest in other more important errors.

But either way, this is an old module and I'm sure there is someone out there who would disagree. I would rather change the behavior under a very minimal, easy to adapt breaking change that have to burden users with more flags.

Anyone care to implement?