This procedure is as follows:
- Before, notify all users of your module who might be affected by this change (see below)
- Remove all distribution files and
- Tag repository with new major semver version (e.g from 3.5.6 to 4.0.0)
- Don’t remove your component from Bower registry (via
To understand why these steps are necessary you need to know how Bower resolves components.
Why step 4?
When Bower sees module name in
bower.json, it tries to resolve it to repository URL by consulting the only centralized part of Bower: its registry. The registry is not as advanced as npm’s. It is a simple mapping from module name to URL of module’s repository. E.g. for jquery:
Bower consults for this information upon each installation (but caches result for some time). It is because it lacks locking known from Yarn and introduced in npm. If you remove this entry, then modules and apps that depend on your module will fail to install. So please don’t unregister your component.
Why step 3?
Because removing support for something is a breaking change. But also because Bower depends solely on git/svn tags for version resolution (it doesn’t care what
version is in bower.json, you can remove it).
If someone reasonably specified
"yourpackage": "^2.3.5" as a dependency, removing support for Bower in
2.4.0 would break her installation. Instead, bump major semver version, and tag it
Why step 1?
bower.json and distribution files breaks all installations that specify in dependcies
"yourpackage": "*" (more likely, resolves to latest semver tag) or
"yourpackage": "master" (less likely, resolves to latest change on master branch). In such case Bower will resolve versions of your package that don’t support Bower. Honestly this is a fault of these developers for not properly using semver ranges for dependencies, but be considerate and notify them to update dependencies in their packages few weeks before dropping Bower support.
Thanks to libraries.io you can fairly easy discover these developers at:
(please replace mocha with your module name)
You can go to these repositories and create issues / PRs that ask to commit (tagged!) patches, ideally for each major version, so these modules depend on proper semver range of your module, and not
You can also notify developers on social channels, because libraries.io won’t list private apps.
Do you think I missed something? Please comment on #2482