Echo JS 0.11.0

Mostly agree... I tend to use package.json (scripts section) and npm as the source of all truth.  I mostly deal with services and systems that have a web front end, and since node/npm have a script manager and are required anyway it just makes sense to me.

I also, likewise tend to have a ./scripts/npm directory in my projects, and most of the references in package.json will call into them (some using cross-env etc).  In the scripts, I use shelljs a lot as it's got a lot of effectively shell-friendly shortcuts.  It's mostly easy cross-platform that way too (linux, windows, mac).

By convention, I tend to use a few specific scripts for specific use cases.

`localize` in order to configure and setup a docker container running local for dev.  Useful for services I'm not currently working on but need running, and having them in the background.

`dev` any initialization for local development, does a `ci` and copies .env.dev.env to .env ... effectively gets it ready to run local.

`build` build for deployment.

`rebuild` or `build-before` for those services that should be built before any other services are built.  Mostly for the db and settings in a mono-repo.  This way the SQL scripts for upgrades and the application settings are ready for the other services to build and integrate their output.  Most of the apps I deal with at work are deployed to multiple clients, so the settings project rolls up (deep merge) yaml configuration and strings.   !default -> client -> client-environment -> client-environment/*.json --- these are then deployed as part of the payload into the specific client/environment... such as client-internalqa or client-clientqc.

`setup` is usually something pushed into the dist package(s).  Some will be actual setup scripts, others will be containers for k8s or similar.  It does vary.

I also tend to prefer to keep all ci/cd configuration and scripts in source control as much as possible, it tends to make it less reliant on specific ci/cd agents/software.  At work, we use Azure DevOps (migrating to yaml configs), but have also used other systems.