npm-on-ipfs experiment feedback

[hacdias]

Tell us what you think about npm-on-ipfs experiment on IPFS Desktop. Thumbs up if you liked it, thumbs down if not, comments for everything else.

[NatoBoram]

Oh. Now that's something I want to try... but I got ipfs/kubo#6467. Can you link more info about that? How to enable it, what it does, and how to use it?

[hacdias]

@NatoBoram the feature is coming on the next release 😃 Not yet here. This is a discussing issue for those who use IPFS Desktop to leave some feedback about the feature. You can manually build IPFS Desktop if you want to have it right now (npm run build).

[NatoBoram]

Sooo I've tried ipfs-npm using ipfs-yarn and, honestly, it's very slow. I also wanted to try it on a pipeline, but it takes so much time and it's so unreliable it'd just completely destroy the whole point of having a pipeline in the first place. I raised some issues (ipfs-shipyard/npm-on-ipfs#121, ipfs-shipyard/npm-on-ipfs#122), but I don't think they encompass everything wrong with ipfs-npm.

[hacdias]

@NatoBoram thanks for leaving your comment here and for raising the issues on npm-on-ipfs repository. Unfortunately, we are aware of the slowness and IPFS performance is a major top priority right now! I hope somewhere during next year we can upgrade performance in a really good manner!

[NatoBoram]

I wouldn't say speed was my top priority when I used it. Here's the priorities I had.

Compatibility with existing tools

Right now, ipfs-yarn is not compatible with yarn and that alone makes it impossible to use ipfs-yarn seriously in a project. If I'm going to be using and enforcing ipfs-yarn in my IPFS-related project, then yarn users should still be able to download dependencies without changing the lockfile. Currently, because the tool doesn't output in the same format as yarn, then that goes out of the window.

One example for this requirement in action is people behind a corporate firewall and pipelines. There's a chance they won't be able to use IPFS at all, and I don't want to give up automated testing just because I use IPFS.

ipfs-shipyard/npm-on-ipfs#122

Don't be invasive

C-based Node modules and node-gyp are extremely invasive and can prevent someone from installing a package altogether. This is utterly unacceptable. Currently, ipfs-npm depends on rabin which depends on node-gyp. That thing breaks pipelines, pollute log files, is invasive, fragile, and doesn't bring any benefits to end-users. I'd rather not have access to rabin chunking than having to deal with a capricious and difficult to install package.

Really, it boils down to this : If I can't install it, then I won't install it.

ipfs-shipyard/npm-on-ipfs#121

Speed

The current speeds is completely unacceptable, but that's just for the first time use. Speeds should get better if ipfs-npm pings the default local gateway first before anything else. Using long-running daemons should be the default behaviour, otherwise downloading dependencies and adding them to IPFS becomes completely pointless.

[lidel]

This experiment has been deprecated.

For more modern approach see https://github.com/foragepm/forage#readme ✨