Build for environments other than 'development" and 'production'
-
I have a Quasar App that I am trying to deploy through Gitlab CI. I am using three environments:
DEV: Hosted with ‘quasar dev’. Works just fine. NODE_ENV = ‘development’. A-OK
PROD: Hosted on IIS. Built with ‘quasar build’. Works just fine. NODE_ENV = ‘development’. A-OK
QA: Hosted on IIS. How to build so I get a NODE_ENV=‘qa’"I need a third env for ‘QA’.
Ideally quasar would pick this up at run time instead of during the build. However, I am not running it on a NODE server and it is not built on the QA server, but rather on a CI server?
What is the best-practice for managing multiple environments beyond the two default environments support by QUASAR BUILD and QUASAR DEV?
Thanks in advance.
-
This feels like a related question. How will we build and DEPLOY both a development and production version of our SPA with 0.15 and it’s CLI.
When deployed our development build/deployment hit our development backend environment, our production build/deployment hit our production backend environment.
We have customized the build process with 0.14.8 successfully to conditionally include a ./config/dev.env.js or ./config/prod.env.js that contains the URL of the related development/production BACKEND environment for the related development or production build.
Here’s the scripts section of our package.json within our 0.14.8 environment:
“scripts”: {
“dev”: “NODE_ENV=development node build/script.dev.js”,
“build dist/dev”: “NODE_ENV=development node build/script.build.js”,
“build dist/prod”: “NODE_ENV=production node build/script.build.js”,
},So, we (1) build and run the development build locally - this is ‘quasar dev’ with 0.15 (2) build and deploy the development build to our hosting service, and (3) build and deploy a production build to our hosting service - this is ‘quasar build’ with 0.15. In other words, we don’t just want to run the development server locally for testing, we must deploy it so others within our organization/user community can test it before we deploy the production build.
Thanks in advance.
-
Hi, use quasar.conf.js > build > env property: http://quasar-framework.org/guide/app-quasar.conf.js.html#Build-Property
Add a property to it then use it in your app instead of looking on NODE_ENV.//quasar.conf.js build: { env: { API: process.env.SOMETHING ? JSON.stringify('....') : JSON.stringify('....') } }
You can then issue “$ SOMETHING=true quasar build …” or “$ quasar build” to differentiate.
Let me know if this doesn’t makes sense to you. -
@rstoenescu - Thank you sir. Your instructions were perfect. I also used the ‘distDir’ property within the build settings to specify the output folder for dev and production builds. Very nice.
-
Ahhhhhh! Much more clever than the goofy hack I devised.
Very good. Thank you.
-
Use a .env file for local development/docker-compose etc
.env
export APP_API_HOST=http://localhost export APP_API_PORT=8080
Change the above values during deployment depending on your environment.
$ source .env
quasar.conf.js
build: { env: { APP_API_HOST: JSON.stringify(process.env.APP_API_HOST), APP_API_PORT: JSON.stringify(process.env.APP_API_PORT) },
If you are deploying using GitlabCI/Docker/K8s or whatever environment injection is probably what you are after anyway.
-
Hey guys! I’m on v0.17.
Having this I don’t know how to proceed:
quasar.conf.js
build: { env: ctx.dev ? { // so on dev we'll have API: 'https://dev.api.com/' } : { // and on build (production): API: 'https://prod.api.com/' },
If I log cxt.env is empty always.
What else is to be done? Should I specify env in the console? How?
-
It will be in
process
property iirc. -
Hi sorry, I’m not sure whether this has been marked as resolved or not.
Seems like I have same concern:
So there will be 3 different environments (e.g: dev, staging, production).
It will also have 3 different API url. (how to set these three up without using dot-env ext which failed in Amplify readability)
It will have 3 different build commands.which one should I do first and how?