* refactor: port check-system to Listr2
* refactor: port 'init' to listr2
* refactor: port 'start' to listr2
* refactor: improve unhandled promise logging
* chore: fix start and init tests
* chore: load local modules first
* chore: force ts-checker plugin to pipe to webpack-infra logging channel
* chore: handle core-utils migration
* chore: move rebuild to core-utils
* Fix "packaging application" log never stopping when building for multiple architectures
There's some kinda complex race condition ish behaviour in the current way the packagerSpinner is handled.
At the moment there's one variable for all architectures, that gets created in one of the later afterCopyHooks, and dismissed both in the first hook, and at the end of all the hooks. This would work if architectures where built for sequentially, but, at least on my system, these builds happen in parallel. Meaning one of the architectures packageSpinners overwrites the other, before the first is dismissed. At the end of the build the second packageSpinner has success fired on it, while the first continues to spin, preventing the process from exiting.
The solution in this commit is far less than ideal.
Constraints:
- Without access to the list of architectures (the function to generate that list is not exported from electron-packer) we don't even know how many architectures we're building for.
- This one is a little self-imposed, and maybe not a constraint for the project, but the code aims not to change any public facing apis. So we need to have one spinner we can pass to the postPackage hook. https://www.electronforge.io/configuration#postpackage
Given these constraints the solution in this commit has one initial prepare / package spinner. AS well as prepare / package spinners per architecture.
One downside is if the afterCopyHooks are executed one architecture at a time, instead of parallelized by architecture, the overarching prepareSpinner could be ended early, (though architecture specific prepare spinners would still be accurate).
* Simplify Package spinners, removing prepackage & making package smarter.
* build: update electron-packager
Co-authored-by: Samuel Attard <sattard@salesforce.com>
* feat!: prefer forge.config.js over package.json config
This change affects the `init` and `import`
commands.
* run lint
* fix tests
* another test change
* fix import
* copy over forge.config files rather than mutate base tmpl
* i broke a test with rebase
* fix lint
* feat: typed forge.config.ts
* chore: extract utils to @electron-forge/core-utils to remove cyclic dep
* chore: update tests for extracted logic in core-utils
* chore: fix tests
Co-authored-by: Erick Zhao <erick@hotmail.ca>
Co-authored-by: Keeley Hammond <khammond@slack-corp.com>
We were falling back to the "best guess" behavior for the forge.config.js scenario, we can do better than best guess and infer a forge project based on a forge dependency
This brings in rechoir and interpret which allow arbitrary extensions / loaders for our forge config.
Notably this allows us to make forge.config.ts a thing (and thus generate type safe configurations).
Samuel Attard
Keeley Hammond
Erick Zhao
George Xu
Jake
Erik Moura
Benoît Bouré
Samuel Attard