he/him 
If you had to install an npm package by URL, instead of by registry name, would you mind? eg. $ npm install https://website.com/package.tgz $ yarn add https://website.com/package.tgz
Show this thread
-
Just to be specific. This is a capability that those npm clients offer TODAY. It circumvents the registry, but that's by design. You can even append a SHA1 hash to the URL to enforce integrity checks, actually safer than the registry because it's author-provided.
Show this thread
PROS: - Author provided integrity hashes - Distributed package distribution - No guardian of control CONS: - No semver ranges (would only work well for top-level dependencies) - Sketchy availability (increased reliance on multiple servers) - Hard to self-host
-
-
git based semver matching is another, albeit much slower, preexisting option. adding semver ranges for tarball deps would require some coordination but doesn't seem entirely implausible (some Well Known URL based off the tarball URL).
-
Yeah that's another option. Strong git support was actually a requirement for of the Yarn partner teams (who no longer actually uses it...). I did a lot of hacks to make it as fast as possible, including use `git archive` which allows you to request a git remote for a tarball.
End of conversation
New conversation -
-
-
Self-provided integrity hashes seems like a security con rather than pro, cause like, where are they gonna get the hash from? Some website, which is just as easy (probably easier!) to takeover/spoof as the download URL itself
-
I guess that’s true. But now if you had write access to where the installation instructions were you could just change the package name to something else. I wouldn’t consider that any better.
End of conversation
New conversation -
-
-
This sounds similar to the way Deno handles dependencies (plus hashes, I guess?) https://deno.land/manual.html#linkingtothirdpartycode …
-
Yeah, slightly. Except with this, you would still continue using the ‘name’ defined by the tarball, so you would still use the alias, rather than the entire package URL when you require() it.
- 1 more reply
New conversation -
-
-
We should use semver ranges together with a per-scope simpler version of the registry. Best of both worlds.
-
The registry manifest could be self hosted and easily mirrored. By scope would make it easier to use.
End of conversation
New conversation -
-
-
IPFS https://ipfs.io (or similar tools) could be used for a distributed storage of package versions.
Thanks. Twitter will use this to make your timeline better. UndoUndo
-
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.