Open kittaakos opened 5 years ago
Depends on: https://github.com/eclipse-theia/theia/pull/6712
For historical reasons, we had to move the electron bundling outside of the repository, because the
electron-builder
could not follow symlinks.
Is it not more because electron-builder
didn't know what to bundle, since the dependencies for the Electron application were hoisted to the mono-repo root with all other dependencies?
So even if we tried to bundle the example app by pointing to the root node_modules
, it would bundle dev and unrelated dependencies?
If so, is it better to have an @theia/example-bundled
electron app which would not be part of the yarn + lerna workspaces? The package.json of this app would refer to the other extensions locally using paths as version constraints? This way would ensure that yarn doesn't mix deps from the other packages with the deps for this specific application. Is this worth a shot?
I got tired of hacking and guessing and opened an upstream ticket: https://github.com/electron-userland/electron-builder/issues/4516
Currently, we have a kind of working solution outside of the repository: https://github.com/theia-ide/theia-apps/tree/master/theia-electron.
For historical reasons, we had to move the electron bundling outside of the repository, because the
electron-builder
could not follow symlinks. In other words, and it is an oversimplification, thepackage.json
of the electron application wasn't next to thenode_modules
folder where the real dependencies were:examples/electron/package.json
andnode_modules
.Make sure we can bundle and not just build an electron application from the source. Otherwise, we have to merge changes to the
master
, then verify it in the bundled electron application. We could try it withdeferSymlinks
.