Build folders and VCS
On of the fundamental questions. There are at least three different, mutually exclusive approaches to this. Consequences of the bad choice for your team may be critical because one approach can't be easily switched to another.
Builds are under VCS. Every commit must include corresponding build changes (if there are).
Builds are under VCS. Every release must include corresponding build changes.
Builds are out of VCS. Fetches and builds are performed as part of install / update process.
|Diffs are huge / messy||yes||kinda||no|
|Conflicts in minimized files||common||possible||impossible|
|All team members must install dev. tools||no||maybe||yes|
|Minified dists unavailable||no||no||yes|
|May break by network disconnect||no||no||yes|
|May break by dep. repo removal||no||no||yes|
|Untested dependency||impossible||possible in staging||possible in production (*)|
|Sources and builds are unsynced||high probability||low probability||zero probability|
|Tags / versions|
(*) – unsyncs between tested and installed dependency version may be prevented to some degree by strict version pinning. Question about deps of deps remains. Solution to is called "shrinkwrapping". Refer to corresponding tool suppport: Bower, NPM But even this don't give 100% guarantee when deps include binary stuff.
Minified builds unavailable
This blocks the possibility to reuse released minified library snapshot in your own builds Your build tool will parse the whole library each time (except incremental builds) getting build time increased.
All projects may be roughly divided into apps and libs.
It's quite clear that the Commit-bound approach is the worst by the Development and History aspect groups. The Unbound approach has the opposite benefits and the worst Deployment metrics. The Release-bound sits somewhere in-between.
So what's to choose when? At this moment we believe that Unbound approach is the best one for apps. It makes development much easier in favor of complicated deployment, but this complication can be solved once and used forever. Tinier history is also more critical to apps, as their commit number is usually bigger in order(s) of magnitude.
It's very uncommon to run build step for libraries manually, so we use Release-bound approach for them.
We never use Commit-bound due to it's super-large history and overcomplicated development, especially when
build includes 3-rd party libs (e.g. always).