Does Bower's flat resolver require manual resolutions for every transitive version conflict?

Answer

Yes. In Bower 1.8.x the flat resolver enforces one installed version per package name in bower_components. When two direct dependencies require incompatible semver ranges for the same transitive package and no compatible single version exists, the resolver does not silently pick a branch. The documented way to break the conflict is a manual pin in bower.json resolutions. Without a resolutions entry the install fails rather than installing an incompatible version.

Confirmed facts

• Flat enforcement: only one version of any package name can exist in bower_components.
• Resolution time: version selection is performed before files are written. Conflicts are detected at graph resolution time.
• Version mapping inputs: dependencies defines the requested ranges. resolutions pins a package name to an exact version to override a flat conflict. ignore controls file copying only and does not influence version selection.
• Persistence: a manual resolution is persisted only via the resolutions object in bower.json. There is no separate lock file. Ad-hoc interactive choices are lost unless written to resolutions.
• Re-evaluation: on the next bower install the entire dependency graph is re-evaluated against the current bower.json. No local cache of previous choices is reused.

Likely behavior when resolutions is absent or incomplete

With no resolutions entry, Bower has no deterministic fallback that automatically satisfies incompatible ranges.

• Interactive runs prompt the user to choose a version for the conflict.
• Non-interactive / CI runs abort with an explicit conflict message and a non-zero exit. The install is not fully atomic; partial network fetches can leave bower_components in a dirty state before abort.

This is likely rather than formally guaranteed because Bower is deprecated and error presentation varies with registry mirrors, Git sources and .bowerrc settings.

Fields that influence final version mapping before install

• bower.json.dependencies – requested ranges for direct dependencies.
• bower.json.resolutions – explicit pin for a package name, applied before installation begins.
• bower.json.ignore – file copy filter only.

Bower does not provide a dependencies override field equivalent to npm overrides.

Steps needed for this case

1. Reproduce the conflict in a clean state: remove bower_components and run install in non-interactive mode to confirm abort vs prompt.
2. Add a resolutions entry pinning the shared transitive package to a version that satisfies both ranges, e.g.

   {
     "resolutions": {
       "shared-pkg": "1.2.3"
     }
   }

3. Run install again and verify bower_components contains only the pinned version and both direct dependencies resolve.
4. Remove bower_components and re-run install with resolutions present to confirm the graph is re-evaluated deterministically without prompting.

One diagnostic detail that changes the recommendation: is the install running interactive or non-interactive? Prompt behavior vs hard abort determines whether you need an immediate resolutions entry or can accept a one-off choice.