Support republishing git dependencies

[andrew]

Currently ipfs-npm-republish skips republishing git dependencies as they need to be downloaded slightly differently, to fully support republishing of ipfs-npm or ipfs then we'll need to properly support those options.

The current setup doesn't break installations because the npm client will go to github to fetch those dependencies, but that means it won't work 100% offline if there are git dependencies anywhere in the tree, and if they have unique dependencies from npmjs.org, they may not be included in the microregistry.

Couple of options:

• check out the git repo, run npm pack, generate a packument and then rewrite the any dependencies to point at the new packument (not great)
• add the checked out git directory to the microregistry and create an ipfs-npm-republish install command that can pull from there rather than trying to go to Github

Those git repos will also need to be checked out when publishing to correctly resolve the full dependency tree. Ideally we can lean on the internals of npm/yarn rather than reimplimenting it all again.

[andrew]

Looks like the pacote library will take care of most of the plumbing, will tackle it this evening.

[andrew]

As of 9f2db41 the dependencies of github dependencies are correctly added to the micro-registry, that means you can republish a module from npm that has github dependencies and the full transitive dependency tree is stored except for the actual github dependencies themselves.

That means it doesn't work offline but it does work without touching registry.npmjs.org.

To make it work offline will require either:

• rewriting the package.json that declares the github dependency to point to a specific version published to the micro-registry
• making a separate hacky install command that intercepts the github: dependencies and loads them from the micro-registry

The second option is much nastier as it doesn't allow the consumers to use which ever client their like (yarn, pnpm etc), the only downside to the first option is that the integrity values for the packages which have written package.json files won't match with the integrity from registry.npmjs.org.