Create an Electron app generator

[chiubaka]

• [ ] Should come with React (#123)
• [ ] Should have a full E2E testing set up (potentially also with Cypress)
• [ ] Should support TypeScript

[chiubaka]

Just playing around with this a little because I'm excited to get here. Messed with nx-electron and am discovering that their mental model is that you create a web-based React app, and then generate a separate Electron app that points to and wraps that app.

This way you get isolation between the Electron wrapper and the React app itself, which I find very interesting. You can then continue to use the existing React app as a web-based app, but now you have Electron stuff you can play with as well.

I actually like this a lot. The set up isn't working out of the box, so I'll probably need to play with that.

[chiubaka]

For E2E testing, if going with an Electron wrapper paradigm, the React app itself should be E2E tested with Cypress.

However, there will be at least a few things that probably should be E2E tested against the full Electron app in order to ensure that Native Modules and Electron-specific code are behaving properly (e.g. if I build an overlay, how might I test that it actually displays over other apps?).

There's some discussion around the web about how Cypress does not support Electron (though it seems like they did, once, and ironically Cypress is built using Electron in some capacity).

Playwright has come up as an interesting possible alternative that does have at least experimental Electron support. This thread has more context.

[chiubaka]

Oh no! Problem with nx-electron: it's built for Nx v13.10.3 and the project has not been updated in... well, quite a while. This is posing a potential obstacle to getting nx-electron integrated and making me wonder if I should either:

1. Upgrade nx for nx-electron so that I can use it
2. Just go ahead and try to replicate what I need from nx-electron directroy

[chiubaka]

Here's what nx-electron is actually doing:

1. Invokes its own initGenerator
   1. Sets nx-electron as the default collection
   2. Initializes Jest
   3. Installs nx-electron, electron, and exitzero
   4. Optionally formats files
2. Copies a bunch of templates
   1. TSConfigs for Electron project
   2. The full code sample for Electron
      1. Event handler examples (including Squirrel and Update events)
      2. Sample app which opens a local web server in development and a bundled HTML file in production
3. Writes a src/app/constants.ts file with variables loaded by the code sample
   1. Name of the Frontend project
   2. Port where the frontend project runs in development
   3. Name of the Electron project
   4. Update server URL
      1. Used for update events
4. Builds a project.json file
5. Generates a linting config
6. Generates a Jest testing set up
7. Generates a generic proxy file for frontend project
   1. Not 100% sure, but looks like this is meant to proxy out to a local development server for the app's backend
8. Formats files (optional)

[chiubaka]

Of the above steps, actually most of it is going to be handled by tooling I've already built internally.

The real secret sauce is in the code sample and the project.json tasks, I think. Which means the executors from nx-electron are actually going to be quite pivotal.

[chiubaka]

Here's some info about the executors:

• nx-electron:build
  • Appears to use webpack under the hood. Not clear to me why it doesn't use or extend @nrwl/web:webpack or @nrwl/node:webpack
  • It may be possible to replace this specialized executor with something more generic like @nrwl/web:webpack
• nx-electron:execute
  • It does look to me like there's some secret electron-specific sauce here.
  • This one feels like a copy or fork situation
• nx-electron:package
  • This uses electron-builder under the hood. There's a good amount of complexity here
  • Copy or fork
• nx-electron:make
  • Just re-uses the package executor.

[chiubaka]

Testing story in nx-electron is reasonable for unit tests, terrible for E2E tests. In upgrading Nx on a fork, I don't know exactly how confident I'd be that I hadn't broken something in actual running tasks for the generated project.

[chiubaka]

Bumping this so that it doesn't appear stale for import into Linear.