Force one dependency version with Bower resolutions

Use resolutions when two components need different versions of the same package

If one front-end component requires jQuery 3.x and another legacy widget requires jQuery 2.x, Bower's normal semver (semantic versioning) resolution can install conflicting copies or fail during bower install. The supported way to break that conflict is the resolutions object in bower.json. It tells Bower to install one explicit version of a package for every consumer in the dependency graph, rather than editing each package's own manifest.

Takeaway: add a resolutions entry to bower.json to force a version, then verify the installed copy in bower_components. Treat this as a temporary override, not a fix for upstream incompatibility.

Worked configuration

Suppose bower.json declares these direct dependencies:

{
  "name": "example-project",
  "dependencies": {
    "jquery": "^3.5.0",
    "legacy-widget": "^1.0.0"
  }
}

legacy-widget in turn declares a dependency on jquery ~2.2.0. Without intervention, Bower sees ^3.5.0 from the project and ~2.2.0 from legacy-widget. Depending on the Bower release, it may install two copies or abort.

Add a resolutions block to select one version:

{
  "name": "example-project",
  "dependencies": {
    "jquery": "^3.5.0",
    "legacy-widget": "^1.0.0"
  },
  "resolutions": {
    "jquery": "3.6.1"
  }
}

When you run bower install in the project directory, Bower records the forced choice and installs that version for all consumers. The versions shown here are illustrative; substitute versions that match your actual packages.

Run the install and check the result

Open a terminal in the folder that contains bower.json. No special permissions are required for a local user install.

cd /path/to/project
bower install
bower list jquery

Expected check: bower list jquery should report the forced version, and bower_components/jquery should contain that release. Do not treat example output as proof; run the command in an isolated test folder first.

Risk: Bower may report success even if the forced version violates a consumer's declared range. The install can succeed while the application fails at runtime because legacy-widget receives a jQuery major version it was not written for.

Limits of the resolutions override

• resolutions affects only the package you name. It does not rewrite that package's own bower.json dependency ranges.
• The override is static. If you upgrade a consumer later, you must revisit resolutions manually.
• It is not a transitive guarantee. Forcing a top-level version does not ensure every nested dependency works with it.
• Behavior can vary across older Bower releases. Test in an isolated environment before changing a production project.

Common mistakes

• Pinning a package that is not actually in the dependency graph. Bower ignores resolutions for unknown packages.
• Choosing a version outside every consumer's acceptable range. The command may finish, but runtime errors can appear.
• Using resolutions instead of updating or replacing an incompatible upstream component. The conflict remains hidden.
• Removing a resolution later without re-running bower install. The installed state can stay stale until the next install.

Rollback

Because editing bower.json and running bower install changes project state, rollback is to remove the resolutions entry, save the file, and run bower install again. This lets Bower resume normal semver resolution and may reintroduce the original version conflict.

Practical verification in a test folder

1. Create a temporary folder with a minimal bower.json that reproduces the conflict.
2. Run bower install without resolutions and note which versions appear in bower_components.
3. Add the resolutions entry, run bower install again, and confirm the targeted package now appears in only the forced version.
4. Load the component in a simple HTML page and check that APIs expected by both consumers are present.

If the runtime check fails, the forced version is too new or too old for at least one consumer. Remove the resolution and address the upstream incompatibility instead.

Deprecation notice

Bower is deprecated and unmaintained. Existing projects using it carry security and compatibility risk, and new projects should not adopt it. Use resolutions only to stabilize a legacy project while planning a migration to a maintained package manager.