Skip to content
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

Is it possible to target electron-renderer? #1738

Closed
michaelchiche opened this issue Jul 16, 2018 · 10 comments
Closed

Is it possible to target electron-renderer? #1738

michaelchiche opened this issue Jul 16, 2018 · 10 comments

Comments

@michaelchiche
Copy link

❔ Question

Hi, I am new to parcel, and I was wondering if there was a way to build with parcel and target for electron-renderer? I saw that there is a target electron, but it removed all the node_modules and then my app does not work anymore?

🔦 Context

I need build for electron-renderer/electron to be able to do:

import { ipcRenderer } from 'electron';

I need access to this in my react app. Parcel worked perfectly to target the browser, but I can't completely switch to parcel until I can build both electron and web apps with it.

I saw that #1690, which looks like it might be the solution to my problem?
because now, when I build with target electron, I get react not found.

Thanks for your help

💻 Code Sample

🌍 Your Environment

Software Version(s)
Parcel 1.9.7
Node
npm/Yarn
Operating System
@Hammster
Copy link
Contributor

target: 'electron' is exactly for this usecase, you probably did not seperate the building for your main (target: node) and render process (target: electron).

A little side advice since i wrote multiple electron apps with building tools in the past, you don't really need to build the main process files, electron understands ES6 and the new 3.0.0 beta can also use the import syntax ;)

@michaelchiche
Copy link
Author

Hi @Hammster, thanks for the quick reply!

To explain what I am doing. maybe it is not the way it should be done?

I have an index.web.js and an index.electron.js file

the index.electron.js needs access to ipcRenderer, but when I do that, it does not bundle react in the electron one.

Is this the way intended? or did I miss something?

@Hammster
Copy link
Contributor

Hammster commented Jul 16, 2018

ipcRenderer is only available in index.web.js it is not meant to be accessed from the main process you would use ipcMain for that . 😉

Feel free to contact me on the parcel slack, by mail, via twitter (@hammster1911) or the new parcel spectrum channel, if you need further help, since this issue is not really parcel related ;)

@michaelchiche
Copy link
Author

index.electron.js is imported in a index.electron.html, it is in the renderer process. I just sent you a DM on twitter. Thanks

@nocke
Copy link

nocke commented Nov 19, 2018

target: 'electron' is exactly for this usecase, you probably did not seperate the
building for your main (target: node) and render process (target: electron).

Hi @Hammster, just to verify and double-check with you:

  • main.js should be --target: node
  • renderer.js (“client-side”) should be --target: electron

Correct?

That would mean, this boilerplate for example is doing it wrong?

If that is true, perhaps we could make that more explicitly clear in the api docs?

Many people appear to run into a seeming import/fs issue, which (if I understand correctly) is related...

@Hammster
Copy link
Contributor

Hammster commented Nov 19, 2018

@nocke that's correct, i'm going to quote some sourcecode for that.

switch (bundle.entryAsset.options.target) {
case 'browser':
ctx = prepareBrowserContext(bundle, globals);
break;
case 'node':
ctx = prepareNodeContext(bundle, globals);
break;
case 'electron':
ctx = Object.assign(
prepareBrowserContext(bundle, globals),
prepareNodeContext(bundle, globals)
);
break;
}

As you can see the electron target prepares a browser context, therefore it is aimed for a render view. In addition to that loosened up from parceljs the electron main process is a patched node, but it does not behave diffrently compared to normal node for the bundles. The render process on the other hand, is a enriched Window that can access even native node modules like fs, and you cannot bundle those.

I would propose the following, to lower the risk of confusion target=electron-render and target=electron-main, having the main and render code in one bundle is pretty much overkill especially if you want to have less memory overhead. but if you still desire so, electron can default to electron-render

so basically the boiletplate is not doing it wrong, but it is bad practice.

EDIT: I've tried the boilerplate, my guess is that something else is off, because the require actually is parsed correctly to the index.js of electron for further handling. And you can evaluate the require('fs') in the console after it.

error

@vudzero
Copy link

vudzero commented Dec 29, 2018

I don't know if it's related, but when I target 'electron' instead of 'browser', the bundler won't load my own modules anymore. Same modules are loaded perfectly fine in browser mode, but then the 'fs' error appears if trying to import ipcRenderer.
image

Info: My own modules are in typescript shared within a mono repo and are not precompiled.

@lukejagodzinski
Copy link

@Hammster are you sure I can use import syntax in the main process? I'm using Electron 4.0.1 and I get syntax error when I try to use import statement. How can I do that without building using parcel?

@Hammster
Copy link
Contributor

Hammster commented Jan 13, 2019

@lukejagodzinski

You need to enable ESM support via the --js-flags see here and here

If you don't want to depend on the node flag for the main process since it is still marked as experimental, you can use the esm package to do it see here

@lukejagodzinski
Copy link

@Hammster using --js-flags doesn't work:

"main:start": "electron --js-flags='--experimental-modules' ."

throws error: Error: unrecognized flag --experimental-modules. And of course my main file is called main.mjs as documentation says.

I've used to use the esm package and it work pretty well but I don't like an idea of the extra file being referenced first.

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

No branches or pull requests

6 participants