Closed brechtcs closed 4 years ago
Good idea!
Any ideas about how it should work?
I was thinking I could have individual webrun-plugin-x
and have the main webrun version attempt to require
some known plugins and add them if the call is successful.
I agree that Dat and IPFS should be optional extras.
I'm currently working on WebTorrent support, so I'll get into this after that's figured out. :D
Yeah, just something like this should be fine. (I think.)
try {
this.addPlugin(require('webrun-plugin-dat'))
} catch (err) {}
try {
this.addPlugin(require('webrun-plugin-ipfs'))
} catch (err) {}
Also I noticed that the non-scoped package name webrun
hasn't been taken on npm. Any particular reason why you're not using that one? (It's happened a couple of times already that I've done npm i -g webrun
, only to be greeted by a 404.)
I haven't taken the non-scoped webrun because I was trying to buy into the scoped packages thing. But I guess I should at least have a placeholder that warns you about it. 😅
Or should I ditch the scoped version and go for the global webrun
name?
Personally I'd just use the non-scoped version, as that still is the most common way to publish things on npm these days. I agree it would be better if scoped packages were the norm, but as long as that's not really the case it feels a bit like swimming against the tide.
I've extracted out IPFS and Dat into separate plugins that get auto-required if they're installed.
https://github.com/RangerMauve/webrun-plugin-ipfs https://github.com/RangerMauve/webrun-plugin-dat
Also published under the global webrun
name. 😁
With the addition of the IPFS plugin, the installation process has gotten a lot slower. Since not all projects will be using this, I think it would be good to have a mechanism to make heavier plugins like this optional.
I can imagine that other people will have similar issues with the
dat
plugin as well, because the sodium-native dependency can be quite a pain on some systems.