The Problem
Scripts in package.json oftentimes rely on prior state or context in order to execute as expected. For example, injecting the right .env files to have respective apps not upload things such as test data into production.
Current conventions for most applications handle this in a few ways:
- Manually add an inline variable to the command such as
NODE_ENV={whatever}, or for node 20+ projects use the --env-file switch. This gets cumbersome when you need to make 3+ copies of many regular scripts (eg. dev|start|build) and the commands themselves have enough other switches to worry about.
- Use external libraries like
dotenv resolve this for them. Any addition of dependencies introduces the classic issues of new surface areas for vulnerabilities, as well as relying on the availability of respective maintainers to update them when contracts change, etc etc. Also, I still haven't found an external dependency that addresses this gap directly.
The Proposal
Allow for an opt-in, zero-dependency solution that gives developers a cleaner, DRYer package.json. Example snippet:
"scripts": {
"serve": "node server.js",
"build": "node scripts/build-client.js"
},
// act as hooks to run before script execution
"hooks": {
"dev": "NODE_ENV=development && NODE_OPTIONS=--env-file=.env.development",
"stg": "NODE_ENV=staging && NODE_OPTIONS=--env-file=.env.staging",
// and so on...
}and when running in the terminal, the environment keywords will then be parsed for as hooks, delimited by : for example, and then execute those commands "pre" lifecycle hook style.
npm run dev:serve
npm run stg:serve
This kind of functionality can be abstracted to other use cases where pre or post lifecycle hooks can be leveraged for any group of scripts that wants to be decorated by them.
The Problem
Scripts in
package.jsonoftentimes rely on prior state or context in order to execute as expected. For example, injecting the right.envfiles to have respective apps not upload things such as test data into production.Current conventions for most applications handle this in a few ways:
NODE_ENV={whatever}, or for node 20+ projects use the--env-fileswitch. This gets cumbersome when you need to make 3+ copies of many regular scripts (eg.dev|start|build) and the commands themselves have enough other switches to worry about.dotenvresolve this for them. Any addition of dependencies introduces the classic issues of new surface areas for vulnerabilities, as well as relying on the availability of respective maintainers to update them when contracts change, etc etc. Also, I still haven't found an external dependency that addresses this gap directly.The Proposal
Allow for an opt-in, zero-dependency solution that gives developers a cleaner, DRYer
package.json. Example snippet:and when running in the terminal, the environment keywords will then be parsed for as hooks, delimited by
:for example, and then execute those commands "pre" lifecycle hook style.This kind of functionality can be abstracted to other use cases where pre or post lifecycle hooks can be leveraged for any group of scripts that wants to be decorated by them.