I have been building my application on web pack and testing using web pack. My biggest concerned is how can deploy it after the application is complete?
Do i need to use the 'Webpack' dev server for production or just deploy direct my 'dist' folder to production.
No, you should not use webpack dev server on prod, and it's particularly said in docs. Yes, you should make a build with webpack, probably using another config (or having conditions in your config, e.g. depending on ENV variables). For example, you would probably want to run minifiers, or hash your files for cache busting. And then you just upload dist to your webserver (if you don't use any CI tools of course, in that case you should run a build there) and run apache, nginx or anything else there.
Related
We have an API that we host via nginx on localhost:3128. That API serves all of our JS/HTML as well as our various service endpoints.
If I run yarn start that will run on port 3000, which means that our fetch requests also go to port 3000, and that won't work since the endpoints are all on 3128.
My plan was to instead run a build, and then upload to our serving API behind nginx for testing. The problem is that yarn build transforms our human readable typescript into minified, compiled javascript. This makes my stack traces and debugging harder.
How can I solve this problem?
General solution to this would be to create some proxy that would redirect your requests from :3000 to :3128. If you use CRA, you can declare proxy in package.json or setupProxy.js.
If you don't use CRA, but use webpack, it is made in similar fashion with webpack-dev-server.
I am writing a nodejs application with Angular as my front end.
For this I am having Git as my code management server.
For client, I am doing minification and it is ready for production.
But I am not sure, how to prepare server side files for production.
Do we need to just copy all the Git folders into production server?.
Let me know the best way to deploy nodejs server application.
You could use pm2 as your daemon to keep your nodejs app up all the time.
Try not to include node_modules in the repo, cause different machines have different setups/installations, you cannot tell if one package would work before you run it unless you npm install them.
If you are familiar with Docker, use it, pre-bundle all (include node_modules) files into the docker image, and you do not need pm2 here, Docker itself can restart automatically. This is the ideal approach.
It really depends on how you (or your company) want to organize the workflow and the size of the project.
Sometimes I too use a GIT repository, because then is really simple to update: just a git pull and (if server files got edits) a pm2 restart N command.
In this way, you dont have to install the whole development stack in order to compile (and minify) the bundles - I guess you work on your local machine where all the development tools are installed.
Keep in mind to use the --dev flag while installing packages that are only required in development mode, so you can keep the production server as slim as possible.
A good practice I found is to add some random tokens inside the final bundle filename (both for js and css) that get then injected inside the final html static files, to avoid the refresh the page loop.
Once you have the bundle files on your dev machine, just upload them to the server (ftp, git, rsync, sshfs mount, whatever you like) and (if server files got edits) restart/reload the node process (Im using pm2 for this, its really great). If you only edited client files, no reload is needed.
Starting from here, there a lot of ways more or less sophisticated to do the job, like git pipelines for example.. but depends on the situation.
Edit: this is a good article about task runner (gulp vs grunt vs vanilla npm), while may be a little off topic, it analyze some aspect of the common deployment process
I'm curious to know how can one manage application settings in an Electron application? I have found some excellent resources here (Where to store user settings in Electron (Atom Shell) Application?, for example) and elsewhere when it comes to managing user settings but couldn't find anything related to managing application settings.
To me, the difference between the two is that application settings could vary from environment to environment (dev/test/production) but would remain the same for all users of the application. They would contain things like API endpoints etc. User settings on the other hand would change from user to user based on their preferences like window width/height etc.
What I have done so far?
I have found this excellent package called config and start using it in my project. Based on the instructions, I have created a config folder and a default configuration file (I will create environment specific configuration files later).
It is working fine as long as I am developing the application. The application is picking up the default.json file properly from the config folder and is applying those settings correctly.
The problem comes when I package the application (MSI, DMG etc.). I am using electron-builder package for that purpose.
The problem with config package is that it looks for config folder inside the application's current working directory and because it doesn't find it in the folder where the application is installed, it simply throws an error. I even tried to manually copy this folder in my app folder (which is where electron-builder makes the packages) but that didn't help either. Ideally I would like to bundle the app settings in application's ASAR file so that it can't be decompiled.
My questions are:
How are people managing application settings for an Electron application?
Can config NPM package be used for that? Or is there an alternative to that package specifically for Electron applications?
I am not using an npm package but my approach is similar to what you have mentioned. I have a config directory with different config files for different environments: dev, test, prod. Then in my package.json I have added environment specific build commands. e.g. For prod:
"build-prod-config": "config/buildProdConfig.sh",
"build-renderer-prod": "webpack --config=webpack.config.renderer.prod.js",
"build-main-prod": "webpack --config=webpack.config.main.prod.js",
"build-prod": "npm run build-prod-config && npm run build-main-prod & npm run build-renderer-prod",
buildProdConfig.sh
#!/usr/bin/env bash
cp config/app.config.prod.js config/app.config.js
echo "Copied ProdConfig to Config"
//This is what a config file looks like
const Config = {
suppDataDirectoryPath: '/suppData/',
builtFor: 'prod',
}
module.exports = Config;
I then require Config whereever I need in my application and use the values. This is a simple thing for now, and perhaps doesn't have the flexibility of the config package you linked to, but it works.
Also, another important thing is that I am not packing my application into an ASAR archive, but I think my approach would still work because I am packing everything into a bundle using webpack.
I've got two projects which I've created:
A web UI built using webpack
A Vert.x webserver written in java built using Gradle
I want to find a way to bring the resulting build dir contents of the first project into the second as the webroot which will be server up using the StaticHandler.
Is anyone aware of a clean way to do this? I want to preserve the two git projects as they are because I like using the webpack dev server for development of the UI and it generally feels cleaner to have them separated.
I was looking at potentially using the bitbucket pipelines build on my repo, however bringing the assets generated by the first project into the build of the second is where I'm facing issues.
You could create a gradle task that before that depends on the jar task (so it runs before it) executes webpack compile into the resources directory. So when your jar task runs it bundles the compiled webpack code.
I would like you to share your way of deploying complicated JS projects, where Grunt or Gulp are used.
For example, grunt build command concats css, js files, puts minified bower dependencies into dist folder. As far as i know, we should not store build results in version control repo, shouldn't we? Also, development environment is not needed on production server.
That is why flow like: git push production, and then grunt build on production server, then restarting it is not a good practice, isn't it?
The purpose o question is to find out, how should I deploy complicated JS projects when:
Building is necessary.
Building should not be done on production server.(Or it is a normal practice?)
Build results should not be indexed by version control system.
Deployment should not be done manually.