-
Notifications
You must be signed in to change notification settings - Fork 11
Idea: Offline-capable Package Manager App #37
Comments
ooh nice. There has been a recurring suggestion around an "artifactory-like" repository manager tool that teams could run; an always on cache of the packages your team / org uses... it'd operate like a self-hosted caching proxy for the packages yout team fetches. When you install a new package, you ask the proxy, and it fetches and caches it for you. The rest of the team would then be fetching from the app rather than the source registry. If such a thing were to us IPFS under the hood, then orgs could mirror each others packages. With customised clients like |
@agentofuser pointed us to https://verdaccio.org ...a popular npm registry proxy tool, that is focused on locally caching the npm modules you use from the central registry, and can be run on your machinen or shared by a team. It has a plugin mechanism too! Adding a way to let verdaccio servers share their caches via IPFS would be rad, and extending it to support IPFS as a transport as per the work @achingbrain is doing in zkat/pacote#173 |
Here's another offline npm cache based on Dat from @mafintosh https://github.com/mafintosh/ims |
As of v1.1.1 ipfs-npm-republish works offline 🏕 If you have already installed a package locally whilst online, it will reuse existing caches for both contents and indexes when republishing to IPFS and you can also install and republish directly from an existing IPFS micro-registry created by ipfs-npm-republish without needing to make any requests to registry.npmjs.org. The only area it doesn't support offline yet is where a dependency is pointed straight at a git repository: ipfs-shipyard/ipfs-npm-republish#7 |
A great idea brainstormed with @jbenet last night that could become an even bigger focus in ~Q3: Offline-capable package manager app
The idea would be to decentralize the package consumption experience such that the full package download/update process could happen entirely offline if there were a node in that subgraph that had the package contents. We could then encourage communities (schools, businesses, conferences, etc) relying on a package manager to have one node (on a larger / well-connected machine) regularly mirror the latest content such that individuals in that community could seed from that node faster/when offline. That'd mean everything in the package consumer workflow should be able to work with this app (package content verification, etc) without external connections/lookups. I expect we'd start with a single package manager with good adoption (such that we'd get sufficient testers/adopters) and that has minimal additional challenges to overcome.
This made me think of the package manager desktop app suggestion (ipfs-shipyard/npm-on-ipfs#94) - which could evolve into a place where you can select the packages within this package manager you want to cache. That'd empower the "beefy node" to select the whole registry to make it available over mDNS and for my personal node to just subscribe to packages I'm using (and pull first from local beefy node(s) if available).
The text was updated successfully, but these errors were encountered: