Installing bower locally if perfectly good. It allows to use different version of bower locally.
The next step is to create bower-cli package that can run local bower installation.
Upgrading to latest version of semver to fix (#1817, #1845, #1851).
Possible breaking changes in regards to the way semvers handles pre-releases.
If a version has a prerelease tags (for example, 1.2.3-alpha.3) then it will only be allowed to satisfy comparator sets if at least one comparator with the same [major, minor, patch] tuple also has a prerelease tag.
For example, the range >1.2.3-alpha.0 would be allowed to match the version 1.2.3-alpha.7, but it would not be satisfied by * or 1.2.3. See [semvers](https://github.com/npm/node-semver#prerelease-tags) additional details.
Update dependencies in package.json to (mostly) latest available
versions.
Updating these dependencies removes warnings when bower is installed
as a devDependency in other packages and keep the code fresh.
Methodology:
- `npm install`
- `npm test` (all tests pass)
- `npm-check-updates -u`
- `npm test` (find errors, suspect semver, back off to `~2.3.0` in
package.json)
- `rm -rf node_modules` (and .gitignored files)
- `npm install`
- `npm test` (all pass, deem updated version compatible)
- revert to package.json from `master`
- `npm install` (install the old dependencies)
- switch back to updated package.json
- `npm install` (upgrade dependencies in place)
- `npm test` (all tests still pass, deem upgrades safe)
As to the `semver` dependency, it seems that updating to 4.x requires
handling breaking changes, which is TODO.
Closes#1622
Semver states
> Major version zero (0.y.z) is for initial development.
> Anything may change at any time. The public API should
> not be considered stable.
We already had a case where a tmp package update (0.0.24)
broke bower install. This can happen again with 0.x
dependencies that can introduce breaking API changes
anytime.
