Let A be an addon in version a1, and let B be a bower dependency of that addon in version b1. The addon installs its bower package through the default blueprint like
afterInstall: function() {
// b1 is the version.
return this.addBowerPackageToProject('B', 'b1');
}
Now let C be an application consuming A. When A is installed using
ember install A
The bower package is actually installed in C. Up to here, things are fine. Now A is updated to version a2, including B in version b2. In C,
rm -R node_modules
npm cache clean
npm install
will fetch A.a2.
- Will A.a2’s default blueprint run and cause C to install B.b2 as well?
- Is this supposed to work?
if the blueprint is run manually, B.b2 actually gets prompted for, that is, you get to see that the project has a bower conflict now and are asked how to resolve it.
I tried it out now, it doesn’t work. If I specify a postinstall script for npm (ember g testaddon
), it doesn’t work either (because npm tries to install the packages in a different order and ember-cli isn’t installed when the postinstall script runs).
What good is it to have blueprints propagate bower dependencies if one does have to check them manually anyway? Am I understanding this wrongly? Is this intended behaviour?
(Kept for reference and discussion; please answer to SO: ember.js - Ember Addons and bower dependencies versioning - Stack Overflow)