3 ms·
> it makes sense for a few scenarios, like a maintainer testing a new version via a private repository server before pushing this update to the public repositor
by joepie91_ 6y ago
> it makes sense for a few scenarios, like a maintainer testing a new version via a private repository server before pushing this update to the public repository.
This is what tools like `npm link` are for, though. You really don't need this sort of fragile and dangerous version selection at all.
- jsmith45 6y agonpm link does not behave even remotely the same as a package installed from a repository, and there are quite a few packages where this does make a difference. Another charitable explanation for the version selection rule is to allow specifying more than one mirror of the registry. Thus if the closer mirror has the latest version it will be used, but if there is a new version in the main registry that has not been synced to the mirror yet, the latest version will be used.
- SideburnsOfDoom 6y ago> Another charitable explanation for the version selection rule is to allow specifying more than one mirror of the registry. Thus if the closer mirror has the latest version it will be used, This is correct, but in light of this being now vulnerable to abuse, this will have to be controlled in mixed use scenarios, which are common, e.g. as I wrote here https://news.ycombinator.com/item?id=26089387 https://news.ycombinator.com/item?id=26089387 > if I run an internal feed that transparently proxies and caches the public one, as well as hosting my company's internal artefacts, the rules now might need to be different between packages? > for e.g. between Newtonsoft.Json (new versions always originate on the public feed, never locally) and "SDCo.GeneralUtils" (new versions always originate on the local feed, never upstream)