Version-controlling Bower packages, compiled CSS, and other production-ready assets

[John Karahalis]

This quarter, MDN is migrating to Bower for front-end dependency management
and Gulp for running front-end build tasks.

As part of this migration, we decided to begin version-controlling Bower
packages, compiled CSS, minified/concatenated JavaScript, and the like. I
don't have a strong opinion about this one way or the other, but there has
been enough discussion within our team that we thought we should bring the
topic to a wider audience.

We also understand that there are webdev teams putting both strategies into
practice, some committing these assets and some not. We would love to hear
what you've learned along the way.

What do you think: To commit or not to commit?

--
John Karahalis
Mozilla
openjck.com

[Matthew Claypotch]

I'm in the 'don't commit' camp, but not militantly so. Commit or do not,
but what's not up for debate is that you should peg every dependency
version in your bower.json to precise versions. Too easy to just type
'bower install foo' and not set a version, and that sets you up for mucho
failure later.

On Fri, Jan 23, 2015 at 9:34 AM, John Karahalis <jkara...@mozilla.com>
wrote:

> _______________________________________________
> dev-webdev mailing list
> dev-w...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-webdev
>

[Michael Cooper]

+1 to pinning versions. Regarding committing: I don't like committing
things that are available elsewhere (generated files, vendored libraries
etc.). In the case of generated files, I think it's too easy for them to
get out of sync, and they should be easy to generate anyways. In the case
of out side dependencies, I'd rather only maintain my code and keep
external things out of the repo. The size (in megabytes) of a repo does
matter, so keeping unneeded things out of it is nice.

On Fri, Jan 23, 2015 at 9:43 AM, Matthew Claypotch <mclay...@mozilla.com>
wrote:

[John Karahalis]

One concern within our team is reliance on third-party resources. By
version-controlling node_modules, for example, we could be confident that
our dependencies will be available whether or not the NPM registry is
available. How do other teams handle that concern?

For whatever it's worth, I feel that we need something between the extremes
of version-controlling dependencies and pulling them down at deploy time.
The former overloads the concept of version-control, making pull requests
less readable, making it possible for sources to be out-of-sync, etc. The
latter introduces a reliance on third-party services. Registry proxies like
bower-cache <https://pypi.python.org/pypi/bower-cache/0.1.4> have come up
as possible solutions to the latter, but they have their own flaws. I would
prefer a creative solution that learns from the best of both approaches.
But maybe that's a discussion for another day...

On Fri, Jan 23, 2015 at 3:40 PM, Chris Van Wiemeersch <
cwiem...@mozilla.com> wrote:

> +1 to keeping compiled/minified/concatenated files outside of the repos.
> from where I stand, that stuff ought to always be gitignored.
>
> the only exception would be if you're publishing a library (e.g., lunr.js
> provides `lunr.js` and `lunr.min.js` checked in to the repo):
>
> https://github.com/olivernn/lunr.js
>
> and then I've seen other libraries hosting minified downloads on S3:
>
> https://github.com/jakearchibald/es6-promise#downloads

[Chris Van Wiemeersch]

You could use something like https://github.com/mozilla-b2g/npm-mirror and
pull down the npm modules and push them to a Mozilla-owned mirror (or you
could even commit the files to a separate git repo if you wanted to).

And then there's this: https://github.com/mozilla/npm-lockdown

The Gaia and Marketplace Payments teams I know have some experience here.


On Fri, Jan 23, 2015 at 1:13 PM, John Karahalis <jkara...@mozilla.com>
wrote:

[Chris Van Wiemeersch]

[Schalk Neethling]

DXR also uses npm-lockdown so, Erik Rose might also be able to offer
help/insight here.

--
Kind Regards,
Schalk Neethling
Senior Front-End Engineer
Mozilla