Level 30
What would be the reason not to do it locally and keep the minified assets in the version control?
Nov 10, 2015
6
Level 5
Running gulp --production during deployment
In the past I normally would build all assets locally and add it to version control. However already recently adding browserify, babel and vueify (as well as changes to elixir) has made it somewhat compulsory for me to run gulp --production during deployment.
The problem with this however, a deployment that typically run for less than 1 minutes now took 7-10 minutes, and the longest events is mix.scripts() which would minify (since I'm using --production) and concat all the javascript files.
I was wondering if anyone has similar problem and what are your solution to reduce the time taken for deployment.
Level 50
@crynobone We have stopped using the mix.scripts & have moved to only using mix.browserify & doing our requires in the js files in a CommmonJS or if lib will support it ES6 format. Our --production was taking about the same length of time that you are experiencing, but we are seeing that cut in half now.
Maybe worth a test for you?
Level 5
What would be the reason not to do it locally and keep those minified assets in the version control?
Our main problems are:
- without using
NODE_ENV=productionvueify compiled components and include a full path in your compiled JS vuejs/vueify#22. - Bower doesn't have a lockfile, we're getting mixed version between developers even when we have the exact custom script.
composer update:frontendwhich would executebower update && gulp. - Development should be using un-minify/uglify version as it would be tougher to debug.
mix.scripts & have moved to only using mix.browserify & doing our requires in the js files in a CommmonJS or if lib will support it ES6 format.
I'm guessing this also support handling vendor asset files which is only available via bower as well. Will put this into consideration.
Level 5
Using elixir.config.production = false explicitly on gulpfile.js and made the minification via browserify (using minifyify plugin) trim down the deployment time to 3 to 4 minutes.
var util = require('gulp-util');
elixir.config.sourcemaps = false;
elixir.config.production = false;
if (util.env.production) {
elixir.config.js.browserify.plugins = [
{name: 'bundle-collapser/plugin'},
{name: 'minifyify', options: {map: false, minify: true}}
];
elixir.config.js.browserify.transformers[0].options.sourceMapRelative = __dirname;
}
elixir(function (mix) {
// ....
});
The only downside is that local environment now stuck with minified version.
Level 16
Yea, if you disable source maps its almost hopeless on a dev machine.
I see the biggest issue with building it during deploy is that you will get version discrepancies between what you tested, and what is deployed, if the server pulls a version other than you intended (as you explained was happening between developer machines as well).
To me there's a risk that can't be mitigated (unless NPM comes out with a lock file).
I, too, have a project that takes about 10 minutes to build because a library that is included (via require, not mix.scripts()) is about 175kb large. I have not found an optimal solution for this project yet, so I understand the concern. Oddly enough the way to make it faster was not to browserify(), but use scripts() on that large library.
Level 5
To me there's a risk that can't be mitigated (unless NPM comes out with a lock file).
You can actually use npm shrinkwrap to build a lock file. https://docs.npmjs.com/cli/shrinkwrap but it's not as fluent as you been spoilt with composer.
if the server pulls a version other than you intended (as you explained was happening between developer machines as well).
That happen with my team when using bower http://bower.io/, it doesn't have any lock file option at the moment.
Please or to participate in this conversation.