-
-
Notifications
You must be signed in to change notification settings - Fork 2.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[RFC] Parcel 2: Better Electron support #2492
Comments
@kitze on twitter:
|
Documentation and options to generate the release, that is exe, app, deb, rpm, etc. |
Once you move away from the most basic examples, there are more than just those two environments to cater for. You have:
If you're loading remote content or want to protect from other arbitrary code execution, it's recommended to disable With Most production apps will also end up with some native modules to contend with and then bundling With Webpack I've managed to get it to bundle main/renderer/preload entry points, including all
new webpack.NormalModuleReplacementPlugin(/^bindings$/, require.resolve('./bindings')),
module.exports = function(str) {
if (str === 'detection.node') {
const result = require('../node_modules/usb-detection/build/Release/detection.node');
result.path = '../node_modules/usb-detection/build/Release/detection.node';
return result;
}
}; |
👋 Electron Forge developer here. I'm very interested in this because I'd like to have integrated support for Parcel 2, like we currently do (in beta) for Webpack.
This is probably for the best, given that there will likely be native modules in there.
I think this is outside the scope of Parcel. You're better off using a tool like Electron Forge. |
@timfish thanks so much, that's really great info! 👍 Sounds like we will need a few more environments, or perhaps options for them to enable/disable node integration etc. We could support detecting the preload script via static analysis as well I think. On native modules, we are looking to support them for both Node and Electron by doing static analysis of |
@malept re generating the release, what do you think about a Parcel plugin using electron-forge or electron-packager under the hood to do this? Parcel is primarily a runner of other tools, be that babel, typescript, postcss, even Rust. It does all of this via plugins, so a Parcel plugin to run electron-forge would make sense I think. Parcel 2 has the concept of "targets", which allows compiling your app for different environments (e.g. browser, node, etc.). One of those targets could be electron binaries of various types. Then all you need in your package.json: {
"electron:osx": "./dist/app.app",
"electron:exe": "./dist/app.exe",
"engines": {
"electron": ">=x.x.x"
}
} I'm probably oversimplifying this, but lmk what you think! |
I should add that the advantage of inverting the model to have Parcel run electron-forge rather than the other way around is that you could take advantage of the other plugins in the Parcel ecosystem to run things like compilers, resolvers, optimizers, etc., utilize the Parcel cache, compile your app for multiple targets at once (electron + web + react native), and more. |
I can see the usefulness of having an Electron Forge plugin for Parcel. However, in order for the development mode workflow of Electron Forge to work (e.g., Since Electron Forge encompasses the entire Electron app development workflow, it also provides a |
Good points! I think there are valid reasons for both workflows to exist. |
@devongovett A great "getting started" Parcel+Electron integration would be a new |
I get the motivation behind that, but bundling node modules is a big performance win for Electron apps, in particular on Windows. In short, file system access and script parsing is a lot slower for many small files than for one big one, so I’d love to see Parcel making bundling easier for Electron apps. That said, it’s true that native node addons are pretty popular with Electron devs and getting this right might be tricky.
I’m not sure that’s a great idea - Forge needs to run plenty of fairly big operations and I’m afraid that inverting the relationship would constrict Electron developers. Web bundling is just one of many steps to a binary (think signing of binaries, releasing to update servers, integrating with app stores) and I’d be concerned that Electron is simply not a big enough share of Parcel users. In other words - Parcel doesn’t quite work for Electron out of the box and I’d need some convincing to trust it with building my apps. |
@devongovett thanks. I didn't know It's also possible to set preload scripts per session. You can no doubt pick these out and automatically bundle them too, but it would be tricky to work out which renderers these will be loaded into and therefore which preload environment to target. |
We adopt Two package.json Structure in our Electron projects. In the outer In the inner Currently we have to write complex Webpack config files (with lots of explanatory comments) to accomplish this behavior in build process. It will be highly appreciated if Parcel can support this, too. |
Hey @devongovett Thanks for opening this issue and moving forward on this. Just wanted to chime in here as an Electron and Electron Forge maintainer that I agree with @malept and @felixrieseberg on their points here. Mostly around:
Weighing in quite heavily on what @frankshaka just outlined above. This is strongly IMO but based heavily in experience in this area. No one should be using the two package.json structure It doesn't solve any problems that haven't been solved with module-tree tracing for rebuilding native modules (what
TLDR is please don't go down the route of two package.json structure. It was an incredibly hacky / bad solution to a problem that has since been solved in much better ways. |
@MarshallOfSound Maybe my information is a little outdated (a few months?), but I’m strongly curious about what are the better ways you mentioned to solve problems we are facing like having the same native module (e.g. If there IS a better way, please do tell me and I would love to adopt it in our projects and replace two package.json structure. |
@frankshaka I've only run across the situation you describe once before (and in fact it was with Although also a "hacky" solution, it beens that standard tooling like |
@MarshallOfSound Thanks for the reply, and it has opened my mind. However, we cannot adopt your solution immediately because our projects relies heavily on npm (and I’m sure that someone may remind me that no one should be using npm now). Thanks anyway. I know this is not the right place to argue the political correctness of the Two package.json strcture (TPS for short), but since Parcel is interested in better support of Electron, let me explain how Parcel can benefit from such structure and why it’s more intuitive.
IMHO, all the complexity of implementing TPS is just because it’s not a standard and thus no tools like to support it. It’s not a standard because most of Electron apps are simply wrappers of their existing web apps! They may even share the same repository with the web app projects. If I were them I definitely not need another PLEASE, consider some support for such TPS usage, and if you don’t want to make it the default behavior in Parcel, at least provide an option to support it, and that would greatly reduce your work as well as ours and make Electron projects more self-expressive. |
@frankshaka I'm not going to have this discussion here to avoid rail-roading this issue. I've made my opinion clear and that opinion is based on years of experience building Electron apps, Electron tooling, and Electron itself. If you want some help/pointers moving off of TPJS I'm more than happy to hear the problems you are solving through it and point you in the right direction for better alternatives. Just ask away in the #atomio Electron slack channel and I'll chime in. I would ask the Parcel team though (@devongovett and folks) to not introduce complexity by supporting TPJS, it is not a recommended technique of either Electron or any of the major Electron toolchains (forge, rebuild, builder, etc.) |
Looks like parcel can't working when I try to build for renderer and main processes (main is nodejs typescript app + createWindow, renderer is typescript frontend). I have typescript on client and server, but currently I have requirement to "pack" it into electron. I know it fully works with webpack. Reason why I choose parcel few months ago - you don't need to configure something. But in that case, looks like it is not working and I currently going to webpack. If devs from parcel implement proper bundling for electron renderer and main, it will be good, and I can migrate to parcel back. |
This is what I've came with too. I'll fallback to something simpler until Parcel gets a native support for Thanks for all the work that goes into this, it is really appreciated! |
Hi @devongovett , First thanks for your work on parcel 2. Thanks again |
Vaguely necro comment, but since this is open and I’ve been eyeing Parcel as a Webpack alternative for an Electron project facing issues cited here: Disabling bundling Right now my webpack + electron-builder configuration might be a weird pile of that made me lose sanity points while putting them together; but crucially it does work despite the mess that having two different binding loaders, two versions of one of them with a breaking change in naming convention, and whatever the hell gRPC does. (Which, for instance, didn’t work with My point being: bundling Node/Electron Main, with node_modules, and with native extensions may be off the beaten path, but it’s not intractable; my hunch is the Electron community could benefit from charting these waters and figuring out best practices that one could point native library authors towards to make their projects compatible, and it seems to me Parcel may be the sort of project for which “implementing an opinionated-ish approach that Just Works” is appropriate. (Because, say, maybe |
Any news? |
In parcel@nightly, #5049 is fixed that added a bunch of features related to JSRuntime to the Electron environment (like using dynamic imports). If there is anything specific, a separate issue with reproducing steps or repository will allow the contributors to fix things faster. |
Is there any status update for this? |
(Note: I know about as much as everyone else who isn't a Parcel maintainer, that is to say, nothing.) I'm generally going to assume the answer is "no" until one of the Parcel maintainers posts in this issue otherwise. It's still on the roadmap (#7345) but it's not one of the immediate items. Probably the best thing you can do at this point is 👍 the issue summary so the Parcel maintainers can know how much of the community wants this feature. Adding "any news", "status update", or "+1" comments, on the other hand, is not particularly constructive. That being said, I just want to reiterate to the Parcel maintainers that once y'all have the bandwidth to take on this feature (and the related Node.js one), please feel free to reach out to the Electron maintainers. I, at least, would be more than happy to advise on the best way to have a bundler handle native modules in a first party manner. |
How is it going? |
I'm also curious how the Parcel/Electron integration is going |
It's going bad. I was not able to figure it out and used vite instead |
I build an Electron scaffold with Parcel 2: idea2app/Electron-Parcel-PNPM.tsx#1 |
Parcel 1 has an electron target, but it is not super well baked. We should improve on it for Parcel 2.
electron
andelectron-renderer
environments.electron
is the main process (node), andelectron-renderer
is the browser environment. They have slightly different characteristics.electron
andelectron-renderer
like we do for node. This means we should ignorerequire
calls to builtin electron modules.BrowserWindow
constructor, andloadFile
method, and add the referenced file as a dependency (similar to web workers and service workers). This should also start a new environment with theelectron-renderer
context automatically.node_modules
for electron like we do for node? (not sure about this one)Related: #1738, #2042, #840.
Please let me know what else would be useful for electron development with Parcel! 😄
The text was updated successfully, but these errors were encountered: