Motivation ("The Why")
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.
Example
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.
How
Current Behaviour
User generated npm scripts cannot define any pre/before or post/after hooks that can be referenced by their key signature.
Desired Behaviour
User generated npm scripts CAN reference pre/before or post/after hooks that are defined in a new section in package.json, using an agreed upon delimiter such as colon (:). The placement of the hook key, either on the left (pre/before) or on the right (post/after) side of the script executes the hook script that the separated key maps to.
References
- Originally opened as an issue in npm/cli
Motivation ("The Why")
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.Example
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.
How
Current Behaviour
User generated npm scripts cannot define any pre/before or post/after hooks that can be referenced by their key signature.
Desired Behaviour
User generated npm scripts CAN reference pre/before or post/after hooks that are defined in a new section in
package.json, using an agreed upon delimiter such as colon (:). The placement of the hook key, either on the left (pre/before) or on the right (post/after) side of the script executes the hook script that the separated key maps to.References