Skip to content
Switch branches/tags

Latest commit


Git stats


Failed to load latest commit information.
Latest commit message
Commit time

Release questions

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.

Negative Aspects




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
Bigger commitsyeskindano
Bigger repoyesyesno
Is complicated no no yes
May break by network disconnect no no yes
May break by dep. repo removal nono yes
Is slow no no yes
Untested dependency impossible possible in staging possible in production (*)
Sources and builds are unsynced high probability low probability zero probability
Incompatible binaries possible possible impossible
 Tags / versions
Are lockednoyesno

(*) – 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).



Web app / lib release questions



No releases published


No packages published