3 ms·
> Developers: less dependencies is better, especially when they're so simple! No! The opposite of that. Lots of little µframeworks, defining composable and gen
by cballard 11y ago
> Developers: less dependencies is better, especially when they're so simple!
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 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/ 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.
- chrisfosterelli 11y agoThe caret character is a specification in NPM, not semver. It's designed to work within the semantic versioning rules to ensure you get the latest version which includes bug fixes, but also won't include breaking changes. 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/ https://nodesource.com/blog/semver-tilde-and-caret/
- goldbrick 11y agoHow do you read an article like the one this thread belongs to and come away with "Seems reasonable, I need more of that"? Trivial dependencies are a code smell, a liability, and an operational headache.
- _ZeD_ 11y ago...and I am in my little python world with "batteries included"...
- douche 11y agoAnd I in Java and .Net world, where it is more like "nuclear reactor included..."
- whatever_dude 11y ago...Only that, in Java, it's not exactly the nuclear reactor you want, which forces you to use someone else's solar power plant, and then they deprecate the original nuclear reactor (because it's known to leak uranium) in favor of a second nuclear reactor, which still doesn't work that well because it's the wrong polarity, so now you have three energy sources available in your project and if you plug your lamp into the wrong outlet everything explodes (see the Date/Calendar mess).
- bigpeopleareold 11y agoLess dependencies are better. This job is to communicate everything you do in a software project: its reasons and its purposes for every piece. For example, application code that will never be in a public API does not need anything as complex and thoroughly considered than a generic library. When it comes to writing a 10 line function that is represented in an existing module, the most likely reason is that I am writing it for my own purposes and without having to explain why I brought in a package to answer a very small problem. 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.
- tehwalrus 11y agoThis dichotomy is silly. You should write as little code as possible to do the job required, and should use only the dependencies required. This might be none, or nearly everything, depending on what your app or library is supposed to do.