I am stuck in vue.js, how to manage multiple env for multiple servers like local, development and production ?
you can create different .env file for different environment like
.env.development, .env.staging, and .env.production and in your package.json create build script like this -
"scripts": {
"build-dev": "vue-cli-service build --mode development --modern",
"build-stage": "vue-cli-service build --mode staging --modern",
"build-prod": "vue-cli-service build --mode production --modern",
}
For details please follow this doc https://cli.vuejs.org/guide/mode-and-env.html
Related
In my Vue JS application I have a file called .env.individual which defines a variable use for making API calls to the backend.
I also have .env and .env.production, etc, all with different values for the API URL variable.
When I run npm run serve -- --mode individual the application starts up and uses the URL found in the .env.individual file. Likewise, when I run npm run serve -- --mode production the application starts up and uses the variable found in the .env.production file.
Given the above I was assuming that when I run npm run build -- --mode individual the \dist would be generated and I could then run npm run serve and the application would use the variables found in the .env.individual file.
Given my package.json file contains this:
"scripts": {
"serve": "vue-cli-service serve",
"build": "vue-cli-service build",
"lint": "vue-cli-service lint",
"deploy": "vue-cli-service s3-deploy",
"release": "npm run build && npm run deploy"
},
What is npm run serve actually doing and why - when I want to use a specific .env.XXX file do I need to specify it exactly?
npm run serve does not run your application from /dist folder. It compiles unoptimized build in memory (RAM). If you want run your optimized build from /dist folder, you can run it by some http server. For example https://www.npmjs.com/package/http-server .
I want to have the ability to run yarn build with the development and production mode, so I have created .env file and add the variable NODE_ENV=development, but when I run yarn build Vue override it. Is there some workaround for that?? Probably I can use some other variable, like CUSTOM_ENV, but it's odd that I can't control the default env variable in a way I want to.
Thanks in advance!
okay, I found the solution, I can use my .env variables in the package.json:
"serve": "vue-cli-service serve --mode %NODE_ENV%",
"build": "vue-cli-service build --mode %NODE_ENV%",
"lint": "vue-cli-service lint --mode %NODE_ENV%",
so now no matter what kind of build I'll use it will use my env variable, without overriding it
How do I configure webpack in vue to produce a production code/build but using a development config?
I have the following two npm scripts:
"build": "vue-cli-service build",
"build-dev": "vue-cli-service build --mode development",
And two config files:
.env.production
.env.development
Now I need to deploy the code to the development server and make sure the code is absolutely the same as in production so I can test it properly first, but I need to use the dev database for that.
Any thoughts on how to make webpack to create a production code with the mode set to anything else rather than production?
It was just a matter of overriding NODE_ENV=production in the .env config file.
So something like this solved the problem:
# .env.staging
NODE_ENV=production
OTHER_VARS=...
And a script:
"build-stage": "vue-cli-service build --mode staging",
This answer states that npm run build creates a dist folder (it does in my case) as well as an index.html file - it doesn't in my case.
Instead I have an index.html file inside my dist folder, and I upload this folder to my remote server, visiting that index.html in my browser displays a blank page with "Hello world" on top (no CSS, no JS).
I couldn't find anything addressing this issue in the docs.
Am I missing something? Why is my app reduced to a mere "Hello world" page once deployed?
If you are using vue-cli, to create dist folder you need to run npm run build.
Also , open your package.json and check your scripts objects. It will have various commands to run and you can chose the correct script to run.
"scripts": {
"serve": "vue-cli-service serve",
"build": "vue-cli-service build",
"lint": "vue-cli-service lint"
},
For vue cli3, mostly you need to run npm run build.
Let us assume we have a Vue.js project build with Vue-cli3 , package.json:
{
"scripts": {
"serve": "vue-cli-service serve",
"build": "vue-cli-service build",
...
}
Also, we have a plan to push our project to a public repository on GitHub, so we need different environment variables for public repo and for the local development.
Vue-cli 3 gives us modes: https://cli.vuejs.org/guide/mode-and-env.html#modes
I have such a files:
.env
.env.development
.env.production
.env.local
.env.development.local
.env.production.local
Content of .env:
NODE_ENV=production
VUE_APP_PATH=http://website.com/
VUE_APP_API_ROUTE=api/v1/
Content of .env.development:
NODE_ENV=development
VUE_APP_PATH=http://dev-website.com/
Content of .env.development.local:
NODE_ENV=development
VUE_APP_PATH=http://localhost:8080/
When I do npm run serve I expect process.env.VUE_APP_PATH will be equals http://localhost:8080/ but unfortunately it stills = http://dev-website.com/.
So, the problem is variables from local env files (i.e. .env.development.local) are not overwrite existed from another env file (i.e. .env.development).
How can I use this vue-cli approach to overwrite neccessary variables? The documentation tells about priority: An env file for a specific mode (e.g. .env.production) will take higher priority than a generic one (e.g. .env). but with .local files it doesn`t work.
You can pass in the --mode option within the npm script. So, in your instance you might want the serve script to look like:
vue-cli-service serve --mode development.local
If you wanted to test out serving your non-local development configuration you could copy the serve script and rename it serve:local and then edit the original serve script to look like this:
vue-cli-service serve --mode development
Which is really the actual default mode for serve out-of-the-box with CLI 3. We've just explicitly set the mode.