4 ms·
Instead of expecting every library to follow best practices, can this be solved in the package manager instead. First of all, require all non-lower constraints
by Too 5y ago
Instead of expecting every library to follow best practices, can this be solved in the package manager instead. First of all, require all non-lower constraints to include a mandatory reason field. Heck, while you’re at it, mandate a reason-field for including the package in the first place, package.json doesn’t even allow comments for describing why a package is included, sigh.
Second, downstream applications should be allowed to easily force an override from an upstream constraint. The constraint might have been added because it broke feature foo in the library but I only use bar so I can accept that incompatibility.
In fact pip’s separation of requirements.txt and constraints.txt does play quite nicely with this model. Libraries could, in theory, provide a constraints.txt file with a tested combination of packages, which downstream applications are free to completely ignore or to use in pip install -c. In practice it’s a fair bit of administration so might be tough to apply. Would have liked to to see some more mentions of constraints.txt mentioned more in the article btw, this is the pip alternative to lock-files, but it is a rather new feature so I guess that’s why author advices pip-tools and frozen requirements.txt instead.
- genuine_smiles 5y ago> Second, downstream applications should be allowed to easily force an override from an upstream constraint. The constraint might have been added because it broke feature foo in the library but I only use bar so I can accept that incompatibility. Yarn has this feature. See “resolutions” in its package.json documentation: https://yarnpkg.com/configuration/manifest https://yarnpkg.com/configuration/manifest
- onion2k 5y agopackage.json doesn’t even allow comments for describing why a package is included, sigh It sort of does. NPM ignores properties it doesn't understand, so you can easily add something like "dependencyReasons": { "react": "Make website go brr" } if you want to. I imagine your actual complaint is that there isn't a -m flag to add a comment when you install something, or a way to list those comments when you list the packages, or a way to enforce the user always adds a comment. It's true that those are missing, and that they'd be very useful, but you can still do it manually if it's important enough to you.
- valenterry 5y agoUnfortunately, enforcing documentation never works. Then people will just put "42" everywhere which makes it harder to find the _actual_ documentation that someone was willing to note down.