Is it possible to have multiple .env production files that can then be specified for use when running npm run build?
I have a web app that distribute to different customers. So I want to build it with different options enabled/ disabled and different icons and api endpoints depending on who it is built for, so right now I am commenting out and uncommenting every time I run my build, but I was wondering if there is a better option.
Related
I'm working in a private enterprise and want to integrate Cypress E2E tests with our gitlab CI / CD pipeline.
Since cypress needs to install a binary zip file, I can't simply run npm i and hope things will work right.
I'm facing 3 options and not sure which one is the ideal way:
Somehow include the cypress binaries during the CI, cache them, and deploy the app image to both test & dev environments. One will serve for testing and one for the actuall app deployment.
(if possible, it is the fastest way since it doesn't require additional image building, and I would
love to see a gitlab-ci.yml example :) )
Use 2 different images -
nodejs-8-rhel7 image - which will be used for app deployments (and is being used currently)
cypress-included image - which will include cypress as well as the app code (and will be used for testing).
In this case I would have to build the app image twice, one with cypress and one without, looks like a slow process.
Use the cypress-included image for both app & testing deployments.
Since our current application base image is nodejs-8-rhel7, I'm afraid changing the base image will cause some trouble (nodejs version differences etc..)
Which of the above is the best option? do you have a better solution?
Thanks!
I develop an application with nodejs and react. I use dotenv for configuration in my different environment.
I use TFS 2017 for build and release my application.
What is the best practise for add my .env file of production environment?
Production configs can be difficult to maintain. You can use any module or even write your own custom module to load environment variable in to your application.
However, maintaining production .env files locally for each product (i.e. committing them or putting them inside your docker image is a bad idea. If you ever happen to change some of those configs, you will have to manually change in the code for each application, build docker image (if required) and redeploy. If there are just a couple of applications, it might be easy. But if the number of related applications grow in size (as usually happens in case of microservice based architecture) - all of them sharing credentials, ips for database connections etc. it becomes a hectic task to manually change code and redeploy all the applications.
Usually, developers tend to keep a central repository of all credentials and environment variables. For examples, AWS offers parameter store and MS Azure offers Azure Key vault. In such a case, all the parameters are fetched during start time, and all we have to do is restart the application.
So usually people set only one global varibale NODE_ENV (as prod or dev), dynamically fetch all environment variables based on NODE_ENV running something like env $(node read-env-variables.js) node app.js.
I'm working on a web application that currently uses vuejs for part of its interface. The back-end is NOT in Node, so there is currently no package.json file or any tool from the typical npm stack in this repository.
We already have a bunch of non-npm dependencies that need to be installed in order to use the repository, so my coworkers aren't too open about the idea of adding another layer of complexity. I can't blame them for that, it's the reason why I use npm scripts and not even gulp in my other projects. I'm tired of spending hours learning and configuring build tools that never end up doing what I want anyway.
But since the vue-cli tool no longer includes the build command, I'm a bit stuck. Is there really no more CLI app to build vue files at all? And if so, what would be the smart way to use vue without webpack? Template strings are not maintainable at all, and <script type="text/x-template"> don't work when you want to use multiple components from multiple files in the same page.
I realize your question says 'without webpack' but you may be interested in backpack - a CLI app i came across for building Vue.js without requiring you to write any configuration code. It is basically webpack preconfigured as a minimalistic build system for Node.js. It provides two commands, dev for live reload enabled development and build for building you project.
I have a project that consists of several nod.js backend applications. The apps are using the same modules (which a placed outside of each ap folder in shared location). The aps they are to be deployed on differnt environments (servers), some code is for test, some for debug as usual.
If I choosed a platform (for example PaaS nodejitsu) for one of my apps, how I'm supposed to send there only production code for one of my apps? I deployed on nodejitsu and it just sends the app folder and uses package.json to configure the app. But there are a bunch of code that is not need (tests) for example and some code is external. And what If I want to obstruct server code too? How this issues are supposed to be soleved?
For front-end applications has a tons of methods to be build for production. I understand that the requirements are different, but didn't find any infromation on best practices fo how correctly to prepare node.js back end application for deploy.
Read section "Keeping files out of your package" in the NPM Developer page. It states following
Use a .npmignorefile to keep stuff out of your package. If there's no .npmignore file, but there is a .gitignore file, then npm will ignore the stuff matched by the .gitignore file. If you want to include something that is excluded by your .gitignore file, you can create an empty .npmignore file to override it.
Add those test files in .gitignore
or make another branch for production in git and push the production branch.
I have a Node.js Express app that I'm hosting on Nodejitsu. I'm already using env switches in Express for dev and prod, but obviously I'm going to need to push to different dev and prod servers.
For Nodejitsu, pushing to these servers requires a simple jitsu deploy, which looks to my package.json for app and domain/subdomain information.
I'm trying to think of the best way to handle the various pushes to dev and prod (and/r perhaps testing, staging, etc. in the future) given the package.json restriction. Clearly I would like to avoid maintaining several git repos, each with its own slightly different package.json.
What kind of workflow would be ideal for handling this?
We are't using Jitsu, but what we do is keep a couple of different version of the confs around in a confs folder. When we go to deploy our scripts copy the appropriate conf/package.json file in to the root dir.
You may be interested in this: https://github.com/nodejitsu/jitsu/issues/134
As Małecki points out in that issue, this can be done with npm scripts. You can have a few script setup in the package.json file(s) that do the appropriate pre-deploy work.