3 ms·
> why put effort in upgrading libraries and exposing yourself to possible issues. Isn't this what the combination of a "package manager" with semantic versioni
by cookiengineer 7y ago
> why put effort in upgrading libraries and exposing yourself to possible issues.
Isn't this what the combination of a "package manager" with semantic versioning scheme actually should automate?
Personally, I think this is where NPM failed and still fails. They should enforce a binary format that ships with header files (and method signatures), and enforce semantic versioning.
If any library doesn't play by the semantic rules, don't let it publish. That's the authority and responsibility that NPM failed to include.
If everybody plays by the semantic rules ... then libraries can be upgraded automatically without breaking anything. And a huge plus: They can be installed as _shared_ libraries, which is such an old concept that it hurts my fingers having to type its advantages.
- OJFord 7y agoHow do you enforce it? Cargo (rust) considered it, using the vastly more information it has about whether signatures have changed than NPM, but rejected it because you can still make breaking changes without changing a function signature, so why claim to detect it if only a subset can be.
- edynoid 7y agoYou can get pretty far with a statically typed, purely functional language. For example, Elm's package manager enforces semantic versioning: https://elm-lang.org/ https://elm-lang.org/ I don't think you can do that with JavaScript.
- OJFord 7y agoYou can always break an API with the values, however much you do with the types. Its effectiveness also varies with how much and well types are used - e.g. whether you return `String` or `Url` to begin with.