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.


  • Admin

    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.