Beaker Plugins. Scan 'app/node_modules', instead of using global modules?

[joshuef]

I've been starting with the excellent new plugin setup, but ran into a stumbling block just now. I'm not sure if it's really a bug or just a documentation fix... so I thought I'd ask before firing off a PR.

The problem I had developing was the use of globalModules, when scanning for plugins.

It's noted:

On load, Beaker will find all modules that fit that name-scheme under ./app/node_modules, and load them.

So I was firing in with a plugin in that folder.. but it wasn't being found. I did some digging and then remembered this bit:

To install a new plugin, install it globally using npm.

I was also a bit confused as dat and ipfs were running, even though I didn't npm i -g those plugins.

Anywhooo. This could be as simple as addressing the protocol plugin documentation just to make it clear that things should be global, but I was wondering about the use of global-modules, is there a reason you didn't want to reference the app/node_modules folder itself and use the plugins as installed there?

I think it would be cleaner to use only the modules as specified in the app/package.json. I have a fork of this utilising app/node_modules setup and working, I can happily PR that.

[pfrazee]

Sorry, yes, the documentation is wrong. I'll update it.

Originally the plugins were located in app/node_modules, but that didn't work for the binary package. I'm open to alternatives.

[pfrazee]

Doc is updated

[joshuef]

that didn't work for the binary package.

For compiling on OSX? Or on other platforms? The fork has compiled successfully on my osx el cap, but I don't have the facilities to check windows or linux at the mo.

[pfrazee]

There are two issues

1. Electron binaries are typically packed into the .asar archive format, which means you cant npm install into the app/node_modules. This page explains why that's done, but the only reason that I care about is the Windows paths. If we find the paths arent an issue in Windows (eg because of npm's new flat directory) then we can stop using .asar. (Note, I currently dont use .asar in the osx build because it breaks IPFS' daemon-launching. If Windows has to use .asar, then I'll need a new solution for IPFS.)
2. The install path is a pain to find, when you install a binary. When you're building from source, you'll do something like ~/beaker. When it's installed, I'd have to do some googling to figure out where it went.

So, that's why I went with the global install.

With all that said, issue #52 is slated for the next release, and I plan to start on it this week. That will provide a GUI for managing the plugins, and non-devs wont have to touch the CLI at all, solving issue 2, above. (Devs will still need to npm link their plugin while working on it, so we could output the node_modules' path in the GUI for them.)

With the GUI solving issue 2, what might work best is, to use a node_modules in the app's userData path (see http://electron.atom.io/docs/api/app/#appgetpathname). Then issue 1 is also irrelevant.

[joshuef]

Ahaaa.

Okay, I was looking at plugins purely as a dev setup, installed before building a final dist. I didn't realise this was going to be aimed at end users needing to install at their leisure! (which is great 👍 ).

Riiight. Then yeh, my changes will only work for developers, pre-build.

#52 should be a great help then for users, and userData as a place to store plugins and keep away from globalModules (or indeed, needing to install node/npm at all) seems like a sound plan.

I'll close this issue then as the docs are updated and my idea isn't really suited to what you're aiming for here.

Thanks for clarifying, @pfrazee !