electron forge

[chadbr]

you might add https://github.com/electron-userland/electron-forge

It's the new wizz bang generator...

[sindresorhus]

I like the idea of making it easier to get started, but I'm not sold on this approach. The tool seems to be very immature, so it's too early to judge it too much. It will definitely conflict with framework specific CLIs. It's also IMHO too opinionated.

There is already a great solution for easily building Electron apps -> electron-builder. It solves all the things. I recently switched to it from electron-packager, and with a tiny bit of config I get binaries for all platforms automatically built on Travis/Appveyor when I publish new versions, auto-update with one line of code, and so much else for free. I was amazed of how much it does and how well it does it.

I would just use electron-builder in electron-forge. That would save you so much work instead of having to reinvent it all (worse). Instead you could focus on the boilerplates, workflow, user experience.

// @develar

[develar]

I would just use electron-builder in electron-forge

Yes. electron-builder handles a lot of aspects and electron-forge as a tool to build is a far away in terms of quality / feature set. electron-builder will be able to pack electron-compile projects soon (or just use babel, see electron-userland/electron-builder#807).

related: electron-userland/electron-builder#1193

[MarshallOfSound]

I left this issue untouched as I wanted to see what the thoughts were without getting involved too much 👍 That being said, I always want to make electron-forge better so this feedback is pretty good.

The tool seems to be very immature, so it's too early to judge it too much. It will definitely conflict with framework specific CLIs

We expose all of our methods/actions as JS API to make it super easy for framework specific CLI's to integrate Electron related tooling into their workflow. For instance electron-forge is currently being integrated into the Ember / Electron workflow over in ember-electron. We don't want to just be a CLI tool, but an easy API as well.

It's also IMHO too opinionated.

This is definitely something I've become aware of as I built it, and I tried to reduce the opinionated nature of the tool as much as I could. If there are still things where you think I'm forcing people to do X a certain way instead of giving them the option can you let me know? A main point of -forge originally was to give everyone all the options 👍

There is already a great solution for easily building Electron apps -> electron-builder

I think this is a misunderstanding of project goals, Electron Forge isn't designed for just "building" applications, it's designed to help you create your entire app from the initial template, through the development phase all the way to publishing.

I would just use electron-builder in electron-forge.

I have had discussions with @develar about electron-builder exposing it's build targets in a forge compatible way so that you can use the Electron Forge dev workflow but with Electron Builder's numerous and varied output targets. Any word on that @develar? 😄

That would save you so much work instead of having to reinvent it all (worse).

I feel I should point out we haven't reinvented the wheel. Electron Forge is the bare minimum "wiring" between numerous community modules that people have been using for years. All of our make targets aren't written from scratch, they simply call the existing supported modules like electron-install-dmg and electron-winstaller.

electron-forge as a tool to build is a far away in terms of quality/feature set.

Ouch 😆 People are already using forge seamlessly in a lot of projects including me in my personal projects, I may be biased (we both are) but I think that in terms of quality the tool is up there and the feature set is pretty much everything you would need to make and distribute an Electron application.

or just use babel

The whole point of electron-forge is to not make the user have to set any of that up, they shouldn't need to and they definitely don't want to. The beauty of -forge (powered by -compile) is that there is no "compilation" step, there are no watch tasks. Everything is done for you, rather automagically. This means the developer doesn't even need to think about "do I need to rerun babel/webpack/tsc/ember" everything is just done for them in a clean, quiet and efficient way.

---

All this being said, I'm not advocating for this to be put on the list 😆 if I wanted that I would have made a PR, I simply want to explain the points you guys made for future people looking at this issue. A reasonably fair assessment of -forge and -builder can be found here electron-userland/electron-builder#1193

The TLDR is electron-forge is actually trying to solve a larger problem than electron-builder can solve and as such I don't see electron-builder as an alternative to electron-forge, it is more of a companion that hopefully one day soon you will be able to use in -forge as well 👍

---

Worth a read: https://beta.electronforge.io
^^ Our WIP docs site which has a much more readable and usable explanation of our CLI / API and other such wonderful things 👍

[develar]

with Electron Builder's numerous and varied output targets. Any word on that @develar?

This task in progress. But packaging (and publishing, auto-update files) will be still not performed by electron-builder. i.e. when electron-builder targets will be available for electron-forge, way "use build to build electron-forge app" will be still recommended and will produce better results for user than electron-forge make.

[MarshallOfSound]

@develar Yeah, informing the user that electron-builder isn't doing the packaging makes sense 👍

As for the publishing, forge allows for custom publish modules as well, so your publishers could technically be exposed in a forge compatible way as well 🤔

Still keen to get this integration going though so the two module seem less like competitors and more like buddies 😆