Skip to content
This repository has been archived by the owner on Nov 6, 2021. It is now read-only.

Can you add more detailed documentation? #2

Open
yansenlei opened this issue Feb 12, 2019 · 9 comments
Open

Can you add more detailed documentation? #2

yansenlei opened this issue Feb 12, 2019 · 9 comments

Comments

@yansenlei
Copy link

Can you add more detailed documentation? And then I wrote some ideas, do they fit in with your design? Look forward to your reply

@DmitryAstafyev
Copy link

join to your request, not enough description how to use it in real life #3

@meteorsnows
Copy link

First, I have to praise the Author willing to explore this uncharted land. Visual Studio Code, Atom have plugin system, so does Hyper.is

But no one yet have dedication and talent to Open Source any concrete reusable piece of the Plugin system. Hopefully someone can a plugin system in Electron, but we all know that is hard, If this system cover only 50% use case, it would already helped a lot.

@DmitryAstafyev
Copy link

Author of this solution suggests a way of using npm programmatically. Problematic of this way was reflected in my issue. The thing is - using npm programmatically doesn't help with buidling plugin base system.

Unfortunately, for now, I see only one way: using preinstalled (for each platform) packages/ plugins. It can be zipped or compressed somehow. If we are talking about backend (process level) it can be "attached" to the main process as a forked process with IPC based communication (main <-> plugin). If we are talking about frontend (render) it depends on the framework. For pure JS it also can be just attached. In any way - the main issue of an electron is: node. Electron as itself is a node, so each module should be installed in the scope of: version of node (electron) and platform (linux, win or mac). If we say: each machine with our app has npm - no problems we can install plugins just using child_process of node. If we would like to avoid from node's dependency - our plugin should have a release for each platform with preinstalled sources. So, we never will use npm in this case, not via child_process, not programmatically.

@DmitryAstafyev
Copy link

DmitryAstafyev commented May 4, 2019

btw, if you will clone vscode or atom, and try just with search to find a usage of npm programmatically, you will find nothing. So, they don't use it. Because it doesn't work (at least for a moment)

@DmitryAstafyev
Copy link

DmitryAstafyev commented May 4, 2019

so, sure, thanks to Author for willing discover "this uncharted land". But.... Let's cover only one use-case.

  1. I have an electron based app.
  2. I have a plugin, which uses node-pty npm-package.
  3. I would like to have a portable app. It means on a machine where my app will be executed: no node, no npm.

Does Author's solution fit this use-case?

@alvarolorentedev
Copy link
Owner

hello...sorry did not got the notification for your opened issues :( ... I will have a look and answer soon

@alvarolorentedev
Copy link
Owner

So i can work in the documentation. I definetly agree that this is not a one size fits all for plugin is just a dependency graber and allows you to have an interface to load dependencies.
For that dependencies to work it will depend a lot if they have dependencies like you commented on the platform they will work on. For that i dont think this is the tool for the job as this os more for working as the dependency loader.
If you dont have a dependency on the platform any npm package will work. If you have a dependency on the platform like you comented I agree either it needs node-pty, in my case i do not go this route but use prebuilt packages per platform by another package that iIown.

This package has already npm as a dependecy so it does not need it a system requirement. If your bundle is correct there should not be a direct dependency on requiring node. Nevertheles I will double check, and start creating examples.

@DmitryAstafyev
Copy link

DmitryAstafyev commented May 30, 2019

@kanekotic thanks for your feedback. But again, you have as the description of your repo

Create extensible electron applications through a plugin architecture that uses NPM (or similar registry) or GitHub as repository for the extensions.

But this solution doesn't cover at least a use-cases with packages, which has some pre-install or post-install actions.

It's not a problem for sure if we are talking about some simple web-solutions. But electron is developed for desktop things mostly. It means: we are expecting many packages, which works on OS level and in many many cases it means our dependencies will have some pre-install or post-install actions.

Would be nice, if you will just reflect this moment in the description of your repo: this solution doesn't resolve cases if a package (plugin) has dependencies, which requires some pre-install or post-install actions.

Also, I'm not sure, npm will work even programmatically without node on the board. Does your solution fit the case, when a user of application doesn't have node?

@alvarolorentedev
Copy link
Owner

🙏 Sorry For the late reply, I did not get the notification so have not seen this issue 🙏

Answering your last question yes it will require node from my perspective.

I will modify the documentation.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants