How Bower Chooses Package Versions Using Semantic Versioning

Useful answer

Bower reads the version range you specify in bower.json, applies semantic versioning rules, and installs the newest published version that satisfies that range. If you want repeatable builds you must either pin an exact version or fetch the package directly from a Git reference.

How the mechanism works – a worked example

Assume you want to use Lodash but are willing to accept any 4.x release that is backward compatible with 4.0.0. You would add the following line to your bower.json file:

{
  "name": "my-project",
  "dependencies": {
    "lodash": "^4.0.0"
  }
}

The caret (^) means "allow changes that do not modify the left‑most non‑zero digit", i.e., any version >=4.0.0 and <5.0.0.

To install the dependency run the command in your project directory:

bower install lodash --save

Where to run: any terminal with access to the project folder. Required permissions: read/write access to the folder and network access to the Bower registry (default https://registry.bower.io). No special privileges are needed.
Expected checks: after the command finishes, look inside bower_components/lodash. You will find either a bower.json or a package.json file that contains a field like "version": "4.17.21" (the exact number will be the latest 4.x release available at the time of execution).
If you add the --save flag, Bower writes the exact version back to bower.json so the file now reads:
{
  "name": "my-project",
  "dependencies": {
    "lodash": "4.17.21"
  }
}

This makes the build reproducible as long as the registry still hosts that exact version.
Limits and common mistakes
No automatic lockfile
Unlike npm or Yarn, Bower does not generate a lockfile that records the exact versions resolved for every dependency. If you rely only on ranges (e.g., "lodash": "^4.0.0") and a new patch version is published, a fresh bower install on another machine or at a later time may pick a different patch, leading to subtle behaviour changes.
Broad ranges can introduce breaking changes
Using a wildcard like "lodash": "*" tells Bower to take any version, including major releases. If a package does not strictly follow semantic versioning, a new major version could break your code without warning.
Registry maintenance
The public Bower registry is largely unmaintained; newer packages may be missing, and known security issues might not be patched. Teams often mitigate this by pointing dependencies directly at Git repositories.
Pinning with Git references
To bypass the registry and lock a specific source, you can specify a Git URL with a tag, branch, or commit SHA:
{
  "name": "my-project",
  "dependencies": {
    "lodash": "git+https://github.com/lodash/lodash.git#v4.17.21"
  }
}

Running bower install will clone the repository at the exact commit referenced by the tag v4.17.21. Inside bower_components/lodash you will see a .git directory; checking git rev-parse HEAD there will yield the SHA that corresponds to the v4.17.21 tag.
Practical verification steps

Create a fresh directory and add a bower.json with a range, e.g., "lodash": "^4.0.0".
Run bower install lodash --save.
Inspect bower_components/lodash/bower.json (or package.json) to see the installed version.
Change the entry to an exact version, e.g., "lodash": "4.17.21", and repeat the install.
Confirm that the installed version matches the exact string and that a second install produces no changes.
Optionally, replace the entry with a Git tag as shown above and verify the .git directory’s commit hash matches the tag.

These steps let you observe how Bower resolves ranges, how pinning works, and how Git sources provide immutable sources.
When to use which approach

Use ranges (^, ~, >) when you trust the package’s semantic versioning and want to receive bug‑fix updates automatically.
Pin exact versions when you need deterministic builds for CI/CD pipelines or production releases.
Fetch directly from a Git tag or commit when the registry is missing the package, you need a fork, or you want to avoid any registry‑based variability.