2

I am working on an application that uses bower.js; it's the first time I use bower, so please correct me if you see anything evidently wrong in my problem description.

------------------------------------------------

Coming from a Ruby background, I expect a package manager to have a .lock file, tracked under git, that tells me exactly which are the versions currently in use. This doesn't seem to happen with bower (am I right?).

A couple of days ago I deleted and re-cloned my repository, and ran bower install, thinking that such command would just install the required versions of the js components.

Then, today I did a one-line fix in a javascript file, compiled application.js using grunt watch, and realised that application.js was automatically filled up with tons of new code from bower component updates I wasn't aware of.

I found out that our bower components were under .gitignore, and that bower install, that I had run a few days ago, had actually updated two components without me noticing it.

When I realised what was happening, I immediately looked into our deployment procedure, which I paste here:

bundle install --path ${SNAP_CACHE_DIR}/.bundle
npm install -g bower grunt-cli
bower cache clean && bower install && bower list
bundle exec cap [our application name] deploy

Is this dangerous? Will bower install update all the components, that are likely not updated in my local version and are not tracked by git, ending up having completely different js code in production?

Adriano di Lauro
  • 469
  • 4
  • 10

1 Answers1

3

Is this dangerous? Will bower install update all the components, that are likely not updated in my local version and are not tracked by git, ending up having completely different js code in production?

Yes, this may happen and can cause problems. Although the impact will be limited as long as your dependency versions are specified as e.g. "~1.2.3", which will lock the major/minor version and only allow patch level updates.

In contrast to bower, the package manager normally used in node.js environments - npm - has a feature/command called npm shrinkwrap, which creates an npm-shrinkwrap.json file which locks down your dependency versions so that it is safe to run npm install afterwards. This is probably what you would want.

However, bower as it stands does not have this feature yet - there is a discussion about it going on on Github e.g. here.

I think there currently are the following options to solve this problem in your situation:

  • Un-ignore and commit your bower_components (very ugly because of the huge amount of noise this produces in git).
  • Specify your dependency versions down to the patch level, e.g. "1.2.3" instead of "~1.2.3".
    • Culprit: If your dependencies have sub-dependencies, they might still be specified on the minor-version level, which means that even if your direct dependencies have a predictable version, your transitive dependencies may not.
  • Stop using bower and use npm instead (interface-/usability-wise, they are almost identical imho) and use npm shrinkwrap to lock down your dependencies.

Cheers, Alex

alexander.biskop
  • 1,822
  • 19
  • 30
  • Thanks @alexander.biskop. Before reading your answer I had already locked to the current version all my components; now that I see the problem of subversions I decided that I'll additionally run "bower install" in local before deploying in production, to ensure that there are no surprises. It's still slightly annoying, not to be 100% sure that my components won't update randomly, but at least, locking the top-level dependencies, the situation is much more stable. I'll consider passing to npm-shrinkwrap in the future. – Adriano di Lauro Dec 01 '15 at 18:27