I'm not sure how it is happening, but both ffmpeg-static and onnx get to their
correct path without this configuration. the paths it gets to is also slightly
different, so it seems that this snippet does not have any effect (at best):
ente.app/Contents/Resources/app.asar.unpacked/node_modules
This migration path was in the last release v1.6.63, and it has now been out
there for a couple of months so apart from some outliers the migration should've
already happened. Even for the outliers, this will increase their cache size but
won't have a functional impact.
Cleaning this code now to reduce the amount that needs to be changed to support
a contextBridge aware cache.
We now bundle the renderer code within the app. So a load-fail indicates
something really wrong, not something we can deal with upfront (the code wasn't
probably even working - e.g. it was assigning to a function parameter
mainWindow, not the actual global var behind it).
From discussions, it seems that it was pre-emptively added but not specifically
requested by a customer. We can bring this back later if needed, or at least
offer better options to clean it, but for now I'm pruning the IPC surface to
reduce the amount of work needed for handling contextIsolation and sandboxing.
Electron also comes with its own type definitions, and from a (possibly dated)
blog post announcing this I got that we should not be overriding it with
@types/node: https://www.electronjs.org/pt/blog/typescript
Things will break, but let's try to fix them. In the current state, this is
preventing us from running `yarn dev` without reverting back to Electron 21.
