Support simple electron support via TARGET_ELECTRON env variable

[danielmahon]

I know there are "umpteen" ways to support running CRA inside an electron renderer process but most are very "hacky" or require ejecting/forking. This seems to work just fine and seems like a simple addition, and it should support most of the electron use cases. Thoughts?

[facebook-github-bot]

Thank you for your pull request and welcome to our community. We require contributors to sign our Contributor License Agreement, and we don't seem to have you on file. In order for us to review and merge your code, please sign up at https://code.facebook.com/cla. If you are contributing on behalf of someone else (eg your employer), the individual CLA may not be sufficient and your employer may need the corporate CLA signed.

If you have received this in error or have any questions, please contact us at cla@fb.com. Thanks!

[facebook-github-bot]

Thank you for signing our Contributor License Agreement. We can now accept your code for this (and any) Facebook open source project. Thanks!

[danielmahon]

Thoughts on this? Anything I can do to help?

[crubier]

I like this!

[stale]

This pull request has been automatically marked as stale because it has not had any recent activity. It will be closed in 5 days if no further activity occurs.

[stale]

This pull request has been automatically marked as stale because it has not had any recent activity. It will be closed in 5 days if no further activity occurs.

[Johnz86]

I like this. Someone needs to resolve the branch conflicts.

[hardywu]

like to have this feature

[stale]

This pull request has been automatically marked as stale because it has not had any recent activity. It will be closed in 5 days if no further activity occurs.

[tsemerad]

Since this just got automatically set to 'stale', I just wanted to chime in that this would help me out quite a bit. Is there any interest by the CRA maintainers in having this functionality?

[iansu]

We're not necessarily opposed to supporting Electron (as long as the changes are minimal) but it's also not a high priority and we don't really have any maintainers who are Electron experts. So there isn't really anyone driving this and we don't currently have the bandwidth to take it on ourselves.

[danielmahon]

I need to update this PR to reflect the latest CRA but it was a SUPER simple 2 line change to allow the Webpack target to be configured for the electron renderer which is already supported. So it’s completely opt-in and won’t affect anything else. I’m sure there is more that could be done but in my initial use case simply changing the target was enough to make electron play nicely.

[crubier]

I may add that this is needed by a lot of people.

[stale]

This pull request has been automatically marked as stale because it has not had any recent activity. It will be closed in 5 days if no further activity occurs.

[crubier]

Up! Don't close please

[danielmahon]

Until this lands in 3.1 I've published react-scripts@3.0.1 with this change at https://www.npmjs.com/package/@danielmahon/react-scripts

[bugzpodder]

I reviewed this PR on technical merits (ie it worked for me). Whether we will start supporting this is still in the air (possibly reviewed in 3.1 milestone). Personally I'd want to see template support before landing this.

[alanzhaonys]

When are we releasing this to production?

[bugzpodder]

@alanzhaonys #5498 (comment)

[Timer]

IMO, there should exist a community-maintained fork for Electron apps. We can even link/suggest it in our docs.

Adding direct support for electron increases our support matrix too much and probably won't get the dedicated attention it deserves.

[alanzhaonys]

IMO, there should exist a community-maintained fork for Electron apps. We can even link/suggest it in our docs.

Adding direct support for electron increases our support matrix too much and probably won't get the dedicated attention it deserves.

IMO, this should not open up the support for electron, but adding the flexibilities for certain users to extend usage of CRA. CRA is a great tool for people who like me that build Kiosk apps. There is not much replacement out there. There are a lot possibilities that you can do with CRA beyond static contents.

[jlarmstrongiv]

CRA 3.1 was recently released. Can we put this PR on the roadmap for 3.2?

[lukasfrank]

CRA 3.1 was recently released. Can we put this PR on the roadmap for 3.2?

Is there actually any roadmap or expected date when the PR get merged? @bugzpodder

[bugzpodder]

This is off the roadmap for now due to concerns about supporting electron apps after the fact. You can fork this project or rewire the configs if you need it today.

[cinderblock]

I'd really like to be able to target Electron without the very hacky workarounds.

What if, instead of TARGET_ELECTRON=true, which implies support for Electron (and locks this to Electron) it was something more generic and implicitly cautionary in its naming?

I'm thinking: OVERRIDE_WEBPACK_DEFAULT_TARGET.

It would probably also be prudent to decouple from the Node function mocks.

So maybe OVERRIDE_WEBPACK_DEFAULT_TARGET=electron-renderer DISABLE_NODE_MOCKS=true.

I might also suggest to not fallback on 'web' but instead undefined (or to not set target in settings at all) and to let Webpack use its own default.

[codepunkt]

This is off the roadmap for now due to concerns about supporting electron apps after the fact. You can fork this project or rewire the configs if you need it today.

What concerns?

[ghost]

Setting the webpack target to electron-renderer is not perfect. When setting to electron-renderer, webpack is assuming that you have nodeIntegration set to true, which is somehow insecure. Instead, most electron apps use the contextBridge API.

Supporting electron is not that easy, however, I have upvoted to merge this PR.