No! The opposite of that. Lots of little µframeworks, defining composable and generic types, is much better than a giant monolith.
The Swift Package Manager is taking this approach, and I think it's great: https://github.com/apple/swift-package-manager#modules
The caret character doesn't appear anywhere in the semver spec, so whatever that does, it's non-standard: http://semver.org/
If your modules are small and well-defined, they probably won't need many versions anyways - they might just stay on 1.0.x forever. If you want to do something different, it might make more sense to just write another module.
I implemented KeyMirror from NPM once. It's a simple array->object transformation. It's been in production for months without issue. But, I initially got guff from my boss over it for not using the package. If anything, the package is just an example proof-of-concept of an extremely simple idea. But, carrying the bloat of another package next to more relevant packages seems to be more important here than just merely owning a simple piece of code like this.
For example, ^1.3.2 will allow anything greater than 1.3.2 but not 2.0.0. It also has special behaviour that makes it more strict for projects with a major version of 0. If your dependencies follow semver then you'll get bug fixes and security updates without having to do anything or worry about breaking changes.
More info: https://nodesource.com/blog/semver-tilde-and-caret/
Trivial dependencies are a code smell, a liability, and an operational headache.