If you're using npm to run shell or node scripts, then you're running your tasks with shell or node scripts. Just because you typed "npm test" instead of "./test.sh" doesn't mean npm is doing anything to help manage your tasks.
npm (more specifically package.json) is helpful in this context for a variety of reasons:
- it's a single, central document listing your important pipelines and their purposes - anyone unfamiliar with your setup can look at the scripts property and get a very good idea very quickly
- it's auto-detected and even auto-parsed by some tools (a Ctrl-Shift-B in vscode, for example, will allow me to select a build pipeline - there's no more well-supported central format for arbitrary loose shell scripts)
- it's a consistent entry point. If you edit your npm script to point to a separate shell script, or to run webpack/whatever instead - anything external (IDEs, CI configs) pointing to npm need not change
The above are not unique to npm, but it's a well-supported, well-understood, and very simple setup that does the above.
Scripts + NPM are better together, for example because scripts executed under NPM have the local packages binaries in the path. This makes it very easy to have a fully locally installed build environment with no system dependencies. And if you do use webpack, it also helps in providing a uniform interface (Is "test" a Webpack target or a script? Who cares, just use "npm test", it'll work either way, also if we change it in the future).
And it's not an either-or case in the real world. Our company has a big Webpack config that does a lot, and still we have 15+ scripts as well (static analysis, inserting copyright headers, sourcemap uploads, 3rd party vendoring, release scripts...). Some things are better in WP (building), while some things are just simpler with a shell script.
