Add opt-in npm-on-ipfs support

[olizilla]

As per discussions over on ipfs-shipyard/npm-on-ipfs#94 we'd like make it easy for ipfs-desktop users to try out npm-on-ipfs, and co-host modules that they install.

• Offer a prompt to install the ipfs-npm command line tools
• alias it as npm or yarn

[olizilla]

There are some UX challenges to solve here.

• Should be easy to opt in to using ipfs-npm in place of npm. Perhaps a checkbox in the settings page is the simplest initial implementation
• Should be easy to undo. If you want to reset back to regular npm then you should be able to just uncheck the box.

I'm sure there are more. @hacdias @ericronne drop any thoughts you have here!

[hacdias]

I agree with the checkbox in settings. Also, I think that on a first run, if we detect that Node.js is installed, we could actively prompt the user.

[hacdias]

So I was implementing this and an issue surged: I was thinking about aliasing ipfs-npm as npm and to do so I thought about replacing /usr/local/bin/npm with our script. Although this would create a loop on ipfs-npm where it'd call itself forever when looking up for npm.

We could set an alias on the user profile but this would require (1) finding the shell they're using and (2) finding a way to do this on Windows.

The other option I see is trying to set --package-manager to the right path.

[lidel]

I was thinking about aliasing ipfs-npm as npm and to do so I thought about replacing /usr/local/bin/npm with our script

This feels risky. I think we need to do a sanity check around this. Is moving binaries belonging to other packages installed in the system better than adding a directory in front of PATH variable?
Think about scenario when someone uninstalls npm. Our proxy be removed.

Unless I am, missing something,
adding a directory to the front of PATH seems the only "safe" way to override third party binaries.

[hacdias]

@lidel I agree that it is risky changing binaries. For now, we decided just to install npm-on-ipfs package and tell the user to use ipfs-npm instead of regular npm/yarn commands. This needs some more thought because changing the variable PATH is not as easy as it seems since it might depend a lot on the shell the user is using.

On Windows it's relatively easy and we already do it to add IPFS to the PATH.

[DavidBurela]

Something to think about, is that a common developer pattern on Windows is to use WSL (Windows Subsystem for Linux).

I have IPFS Desktop installed on Windows and use it for my general use. But then I open WSL Ubuntu and use the Node development tools in there. It has access to all of the local disk and ports. So just detecting PATH= on Windows is not enough, but needs to be more generic.

[hacdias]

@DavidBurela WSL is still running on a separate "world" so it will also be harder for us to detect the presence of Node.js on those situations. What if the user has 3 different distributions, all with Node.js and then they also have Node installed on Windows itself? What would you do?

[DavidBurela]

I think I misread how it was going to be detected. My thoughts were that all of the environments had access to the IPFS node running on localhost, so that can be used.

But after re-reading I realised that IPFS-Desktop simply looks up if it has access to npm, and if it does it tries to run npm install -g npm-on-ipfs (or prompts user to manually do it).

You can ignore my notes.

[ericronne]

This might be a good chance to co-opt @fsdiogo's help system. Each IPFS Experiment could be automatically installed upon release, and the user notified upon app launch, and offered the option to disable it, e.g. …

Settings could be home base for managing these add ons.

[ericronne]

And a less obtrusive, opt-in option …