When should we minify front-end assets?

[contolini]

Should every project have a gulp/webpack minification step? Should only cfgov-refresh minify JS/CSS and our external front-end deps (like Atomic Component) not? Should none of our projects minify assets and instead we do it as part of our Jenkins deployment pipeline? Should we start advocating a flag to toggle it on and off? From @anselmbradford:

The way I've been seeing to do this is set NODE_ENV and have a development and production setting https://stackoverflow.com/questions/25956937/how-to-build-minified-and-uncompressed-bundle-with-webpack

I like the NODE_ENV technique.

See discussion at https://github.com/cfpb/AtomicComponent/pull/11#discussion_r140347891

[anselmbradford]

Related: I always thought it was a mistake in cfgov-refresh that we have e.g. common.js, which was minified instead of common.min.js, but now I'm having second thoughts. It complicates things in terms of file paths to have the minification designated in the filename—it's all JS regardless of whether it's minified or not. Is there any real gain in knowing it's minified before opening the file?

[wpears]

HMDA builds/minifies when deploying in Jenkins, with a NODE_ENV flag set to 'production' (which some dependencies require to serve the correct version, a la React, which serves a version without certain dev features when NODE_ENV is production). The script that is run is part of the project though, and lives in package.json. There's certainly something to be said about centralizing all build tooling / optimization knowledge in Jenkins so projects don't need to worry (but that also makes local optimization more difficult, if you need to enable certain features in your build for optimizations that make sense only in your use case).

[jimmynotjim]

@wpears could we use a flag locally to get around that problem? Something along the lines of npm run build --prod that runs the same build script in package.json as Jenkins would?

[wpears]

If you wanted to mirror the production build and are choosing which code path to take based on the production envvar, I'd say just export NODE_ENV=production would be a good bet. Otherwise you could have separate tasks build vs build:prod etc.