Bower Dependency Resolution and Package Name Conflict Overwrites

Answer

Bower resolves to a flat tree with one version per package name in bower_components. When the same package is required by multiple dependencies with different version ranges, Bower does not error by default. It silently keeps the version that is resolved last in the current install pass, and an explicit version in the root bower.json overrides transitive requests. There is no .bowerrc option to turn silent overwrites into a hard resolution error.

Confirmed facts

• Bower uses a flat dependency tree. Only one copy of a named package can exist at the project root.
• The root bower.json is authoritative. A version pinned at the root overrides versions requested by transitive dependencies.
• Bower does not provide a native .bowerrc setting to disable silent overwrites or force a failure on version conflict.
• Manual conflict management is via the resolutions field in root bower.json and explicit pinning.

Likely explanation for overwrite priority

Bower resolves depth-first. The exact priority of a conflict in a single bower install is order-dependent on the traversal of the dependency graph and the order dependencies are listed in bower.json. In practice this is observed as a last-one-wins outcome: the version written last to bower_components during that pass is the one that remains. This is implementation behavior, not a documented deterministic ranking.

Assumption: Bower 1.x. Behavior is deprecated and not guaranteed across forks or old caches.

Steps for this case

1. Check what is actually installed.

bower --version
bower install --verbose
ls bower_components

2. Identify the conflict in the graph.

bower list

3. Pin the desired version at the root to make the outcome deterministic.

{
  "dependencies": {
    "package-name": "1.2.3"
  },
  "resolutions": {
    "package-name": "1.2.3"
  }
}

4. Reinstall and verify.

rm -rf bower_components bower.json.lock
bower install

Silent overwrites can cause runtime errors if a dependent relies on an API removed in the winning version.

One diagnostic that changes the recommendation: which Bower version you are running and whether a resolutions block is already present in the root bower.json. If you are on a very old Bower release or using a custom resolver, the traversal order can differ.