Lock Transitive Dependency Versions with Bower Resolutions

A shared dependency with two different version requests

Imagine a front-end project where one plugin requires jQuery 1.12 and another component requires jQuery 3.x. When you run bower install, Bower may install only one version or emit a conflict warning, leaving your application to load whichever copy happens to resolve last. Code written for the older API breaks silently, and debugging the mismatch takes longer than the original feature work.

This is a transitive dependency problem: your direct dependencies list packages in bower.json, but those packages can request their own dependencies. Bower's resolutions field lets you override those nested requests and force a single version across the dependency tree.

How resolutions work

The resolutions object lives in bower.json alongside dependencies. Each key is a package name, and each value is an exact version, a semver range, or a Git endpoint. During bower install, Bower evaluates resolutions before fetching packages, so a nested request for an older copy is replaced by your forced version.

Resolutions apply to packages from the Bower registry and Git endpoints. They do not affect packages installed from local file paths or direct URLs that bypass the resolver.

Worked example: forcing a single jQuery version

Add or edit bower.json in your project root:

{
  "name": "my-frontend-app",
  "dependencies": {
    "legacy-plugin": "~1.4.0",
    "modern-module": "~2.1.0"
  },
  "resolutions": {
    "jquery": "2.2.4"
  }
}

Run the install from the directory that contains bower.json:

$ bower install

You need write access to the project directory and to bower_components, where Bower downloads packages. Watch the install output for a line indicating that Bower overrode a requested version because of resolutions. Afterward, open the installed package manifest—for example, bower_components/jquery/bower.json—and confirm its version field reads 2.2.4.

If a direct dependency genuinely requires jQuery 1.x, forcing 2.2.4 can remove events or methods that plugin code depends on. The override may succeed at install time while producing runtime failures later.

Trade-offs and limitations

• Registry and Git only: resolutions do not apply to local paths or URLs that bypass Bower's resolver.
• Hidden incompatibilities: forcing a version can mask conflicts instead of resolving them, which may surface as bugs in production.
• Deprecated toolchain: Bower is no longer actively maintained, so future front-end tooling may drop support for this field entirely.

Verify the result and roll back if needed

To verify, install a dependency that requests a different jQuery version, then inspect bower_components/jquery/bower.json. The resolutions version should win. If the forced version causes failures, revert bower.json from version control, delete bower_components, and run bower install again to restore the previous dependency tree.

Use resolutions sparingly and plan a migration

Treat resolutions as a temporary truce, not a permanent architecture. Audit which packages request conflicting versions, override only what is necessary, and document why each override exists. For long-term projects, migrate front-end package management to npm, Yarn, or a modern bundler that still receives security and compatibility updates.