- #NPM CONFIG SET NOT WORKING INSTALL#
- #NPM CONFIG SET NOT WORKING SOFTWARE#
- #NPM CONFIG SET NOT WORKING CODE#
I ended up learning a lot about npm that will help me out a bunch in the future.įor the most part, I tried to write up a unique description of each parameter (different from the help docs). Not only do I think this could be helpful to the readers, but it was extremely helpful to me to look through all the different flags/parameters and to actually test them out. After reading some of the help documentation recently, I thought it would be helpful to write up details on as many of the npm configurations as possible. Throughout my use of Node, I only ever knew the basic npm commands like save, install, and publish, and even then I didn't really know the optional parameters that went along with them. Package management can really make or break a language, so ensuring that it is easy to use and flexible is extremely important. env.The Node Package Manager, or npm, is one of the best parts about Node, in my opinion. For example, the variable SETTINGS could be development, staging or production, and NODE_ENV will be always be undefined or production. Use another variable to pick the environment settings, and leave NODE_ENV alone. Otherwise some script might still be executed against production, which is. You have to be 100% sure that every script - start.js, knex.js, db/migrations.js goes through the same override first. Override _ENV in every entry point with a different variable like FORCE_NODE_ENV 1 We got burnt by this once - good thing we have noticed error reports from staging being written to the production dashboard, and figured why the staging server was running against production before any production data was corrupted.ġ.
![npm config set not working npm config set not working](https://user-images.githubusercontent.com/29531779/57759423-7ebb9600-772c-11e9-81ff-20ecd4514104.png)
Server starts with _ENV=production value! But if you have NPM script start that does the same in package.json the result will be different. So the server will behave differently if you call node.
#NPM CONFIG SET NOT WORKING INSTALL#
There is an additional environment variable we can set to install only the production dependencies on staging - it is NPM_CONFIG_PRODUCTION which acts just like -production during install step.īut watch out! Setting NPM_CONFIG_PRODUCTION=true during install overrides NODE_ENV for all npm scripts, which is what NPM intended.
![npm config set not working npm config set not working](https://i.stack.imgur.com/egrv2.png)
Modifying npm install call with conditional to add -production flag when running on staging and production would create a nasty shell command. Staging would run just fine if one of the dependencies was saved as dev dependency by mistake, but the same application would crash in production because that dependencies would not be present.
#NPM CONFIG SET NOT WORKING CODE#
This value then lets my code load right config for the environment. When running on staging or production, I set NODE_ENV variable on the server to staging or production. Often, it is a YAML or a JSON file with environment names as keys 1 NODE_ENV || 'development'ĭepending on the NODE_ENV my program could load different settings: urls, logging parameters, server routes. By default, the environment variable is unset and defaults to development 1
![npm config set not working npm config set not working](https://i.stack.imgur.com/gk6FE.png)
I often use NODE_ENV environment variable to flag these three environments.
#NPM CONFIG SET NOT WORKING SOFTWARE#
If the staging environment works correctly, then I will deploy the software to production.
![npm config set not working npm config set not working](https://i.stack.imgur.com/FAxHm.png)
I write software locally, push it to remote Git server, where if the tests pass it gets deployed to staging environment.