We Keep Coding

How to create a build for multiple environments in Nuxt?

I am building a Nuxt application where I will have two environments staging and production, the local should also be considered as staging, now I need to create some commands and generate builds for production and staging, which will be deployed on two separate servers.
I have two questions
The command
npm run generate
always generate a production build, I checked it using
console.log(process.env.NODE_ENV)
How can I generate a new build where the env should be something like staging?
I want to create some .env files for holding some env related variables, but I am confused about how can I create multiple env files for multiple envs (staging and production).
I understand my question is a bit of research orientation, I spent days researching on the internet, but either the blogs are unrelated or confusing. I never really got what I was looking for, can someone point me into the right direction?

As told above, you can do
NODE_ENV="staging" npm run generate
while building the app, even tho this is not recommended and you should probably just use another env variable like ENV and make conditionals based on this one for your app.
If you want more details on how to use env variables, you can look at this answer.
Then, the way env variables work still applies to what I said about AWS/Heroku etc...

use nuxt --dotenv and pass the path to your env file like .env.production
Example package.json:
{
"scripts":{
"prod":"NODE_ENV=production && nuxt --dotenv .env.production"
}
}

Install different version of npm packages in package.json conditionally

I'm developing a web app which uses a private package.
In some circumstances, I rather to use the local version of the package or different version of that package.
Is there any solution to indicate to use different version of package in package.json?
i.e:
npm install --local
while my package.json looks like:
...
"dependencies": {
...
"my_package": if(local) "address_to_local_package/" else "5.6.1"
...
}

npm does not accommodate this (and honestly, probably should not). This seems like the type of thing that is usually handled at runtime via the NODE_ENV environment variable or similar mechanism. The module changes behavior depending on whether NODE_ENV is set to "production" or "development". (But that's just convention. You can use values like "local" if you want.) So rather than installing different versions of the module, there's a single version that behaves differently based on the value of that environment variable.
If you really want different code bases installed entirely, it will take some effort but you can write a postinstall script for npm to run. Your module then becomes nothing more than a script and then the postinstall figures out what to actually install based on environment variables or maybe a command line flag. This seems brittle to me, though. I'd think hard about if you're solving the right problem here if you go this route. NODE_ENV seems more elegant and conventional.

Configuring globally installed eslint

I installed globally eslint#4.2.0 and wanted to use some predefined configs. When I tried to install eslint-config-google it said that I don't have eslint>=4.1.0 (which I had of course, but installed globaly). The same problem occured when installing eslint-config-airbnb-base - ultimately predefined configs can't see globally installed eslint (and even eslint --init can't see it cause it installed another instance of eslint locally when I run it). Then I decided to install both eslint and configuration files locally, in my projects directory - works like a charm, but still I'd like to have these things in global scope so I wouldn't have to care about it each time I make a new directory for my projects.
Is it possible to make eslint and predifined configs work at global scope or at least have global eslint and local configuration file?

ultimately predefined configs can't see globally installed eslint
Actually, they can. Or rather, global ESLint can use global configs. It just doesn't know how to cross the barrier between global and local.
Then I decided to install both eslint and configuration files locally, in my projects directory - works like a charm
Good choice. This is going to be crucial when you eventually have projects with conflicting needs.
but still I'd like to have these things in global scope so I wouldn't have to care about it each time I make a new directory for my projects
That is what project scaffolding tools like Yeoman are for. Here is the one I use, generator-seth.
Whenever I start a new project, I simply type seth and answer a couple of questions and it's done with glorious magic under the hood.
Is it possible to make eslint and predifined configs work at global scope or at least have global eslint and local configuration file?
Yepp. You can have a local .eslintrc file and the global ESLint will respect it. You can run eslint --init to set this up (that will also install ESLint locally, but you don't need to use it).
But an even better way is to use XO, which is built on top of ESLint (and supports all ESLint rules). Unlike ESLint, XO knows how to automatically choose the appropriate installation to use. You can install it both locally and globally and its global CLI will defer to the local copy when one is detected. This is important because it means that each project can keep its own version of the linter while still allowing you to run XO globally. So if a breaking change comes out, your projects are not screwed all at once or broken when they have conflicting needs. The configuration for XO is kept locally either way, so unlike ESLint you do not have duplicate local and global configs.

I have recently encountered the same issue, here is my solution (OS: Windows):
First, I run eslint initial command to configure my preference:
$ eslint --init
? How would you like to use ESLint? To check syntax, find problems, and enforce code style
? What type of modules does your project use? CommonJS (require/exports)
? Which framework does your project use? None of these
? Where does your code run? Browser, Node
? How would you like to define a style for your project? Use a popular style guide
? Which style guide do you want to follow? Airbnb (https://github.com/airbnb/javascript)
? What format do you want your config file to be in? JavaScript
Checking peerDependencies of eslint-config-airbnb-base#latest
The config that you've selected requires the following dependencies:
eslint-config-airbnb-base#latest eslint#^4.19.1 || ^5.3.0 eslint-plugin-import#^2.17.2
? Would you like to install them now with npm? No
Second, I copy the ".eslintrc.js" file that eslint generated locally into my user home directory (C:\Users\username) to make it a global configuration file.
Finally, I use npm to install the required packages globally:
npm install -g eslint#^5.16.0 eslint-config-airbnb-base eslint-plugin-import
*Important*
Don't use npm install -g eslint because it will install the latest eslint version
(like 6.0.1) and therefore, the dependencies of eslint-config-airbnb-base and eslint-plugin-import will go wrong
And here is the article you may find more information if you want configure differently How to globally set up eslint in vscode.

Node package priority, global vs local

I've noticed that I have Angular 2 installed globally, and I don't know when I might have done that, or if that's the way it's supposed to be. It doesn't seem like that would be necessary if it's defined in every project.
It makes me wonder what side effects that have if I had different versions locally and globally. Which one takes priority? What's the best way to remove all of the Angular packages.

Globally installed NPM packages really only impact your command-line environment. Things like pm2 or sequelize insert bin/ stubs into the PATH to make your life easier.
In order to require something it needs to be present in package.json as well as properly installed.

Webpack: Separate production and dev builds

I have recently started to evaluate webpack. Having used grunt previously I am used to the fact that I can start grunt with various parameters to configure what is going to happen during the build. For example:
grunt watch
would run a debug build and enable the watch task. While:
grunt build
would trigger a fully minimized production build that has all development specific functionality disabled.
I am wondering if webpack has a similar feature that lets me easily switch between different configurations. I have done some research already but I did not like the approaches I have seen so far:
I saw a suggestion to specify NODE_ENV=production before calling webpack, but this is not platform independend (e.g. does not work on windows).
Using the -p switch, but that seems to only affect minimization
Using a separate config file for webpack, but I would prefer a solution where I do not have to maintain two separate files.
I understand that webpack is not actually a task runner such as grunt or gulp, but rather a module bundler. But its being promoted as a replacement for grunt or gulp see this Medium.com Blog.
What I would really like to see is the ability to get a development build with something like webpack watch and a production build with webpack or webpack build is that possible with webpack

First of all, if you use webpack-dev-server it is quite easy to understand you are in dev mode:
let isDevMode = process.argv[1].endsWith('webpack-dev-server') || process.argv[1].endsWith('webpack-dev-server.js');
First condition is for Linux / mac, the second is for Windows.
and then use this to configure your files.
If you are not using dev server you can pass any parameter while running the webpack as you would do with any nodejs script (I use minimist to read the parameters but it is just a sugar, don't use if you don't need to):
let argv = require('minimist')(process.argv.slice(2));
let isDevMode = argv.dev; // or watch or whatever you want to pass
and then call it that way:
webpack --dev
This is actually a very flexible way of doing lots of things, not only specifying dev mode. I use it also to specify bundle names, etc. The only thing you need to care about is avoiding using the parameters which are served by webpack itself.