Why not electron-packager / electron-builder?

[black-snow]

Hey szwacs, I'm currently working on #149. Seems like most tools (e. g. this) are tailored to electron-packager. I wonder why we aren't using electron-packager within the boilerplate.
Was it just too new or didn't exist back then? Are there any advantages in favouring NSIS etc.?

I think we should consider / discuss moving to electron-packager / electron-builder.

On a first read electron-packager sound familiar for it's suggesting the "Two package.json structure". Our release directory seems to be pretty much what's build there.

PS: I don't think that my app has outgrown this boilerplate yet. And even if that was the case it'd be way easier dropping the boilerplate if it was using the "common build process".

[szwacz]

Your hunch is correct. Those tools weren't there yet (or were inmature) when I was building packaging process for this boilerplate hence I wrote it myself.

I was wondering about switching to electron-packager some time ago, but since I'm very busy now I procrastinated until community pushes me into that direction or even suggest a PR ;).

electron-builder looks veeeery promising. Somehow I wasn't aware of this project's existance until today (doh!). This looks like the tool I was dreaming of when starting this project.

All contributions/PRs about moving to electron-builder will be greatly appreciated.

@black-snow since you're active participant for some time here, and if you have time and willing to help/lead this code change (somehow I have gut feeling it won't be that easy process) we can talk about commit rights for you (hit me up on priv to talk about that).

[black-snow]

Great, I'll do some experiments and report back :)

[bayleedev]

I'm excited about this functionality, do you need any help @black-snow ? I'd love to see this get in.

[black-snow]

@blainesch Please feel free to do some experiments and report back your results.
Actually I'm wondering what use is left for the boilerplate if we switch to electron-builder. What does the boilerplate actually do (apart from the little helpers) that electron-builder does not?

The boilerplate does:

• Build installers (covered by electron-builder)
• Install native modules (covered by electron-builder)
• Have some little helpers
• Provide an environment that automagically hotswaps code-changes (if possible)
• Provide the env-config
• Provide harmony transpiling and rollup stuff

Am I missing something? I guess we could swap the build process and still have some additional features that are nice to have. The result would be electron-builder with sensible defaults, helpers and code hotswapping. Neat indeed. On the otherhand I'd mean to swap out like 90% of the boilerplate.
Guess it's up to @szwacz to decide where this project is gonna go. It could also remain as a viable alternative to electron-builder (or electron-packager). I'd say that if you don't need autoUpdate this boilerplate in fact is an alternative.

Guess we should rather take a look at what people need instead of trying to preserve what we have.
In my case it's this:

• Easy to set up environment with debugging helpers (i. e. git clone && npm install && npm start and we're good to go)
• Able to produce installers for all major platforms
• Install native modules seamlessly
• Be interoperable with defacto electron standard tools
• autoUpdate-able
• Fast & good support in case of trouble (szwacz is doing a great job here)

How does your workflow look like? What are your needs? What's bugging you w/ this boilerplate? What's great about it? Should we aim to be a standard tool or rather be an alternative?

[szwacz]

What I wanted to achieve starting this project is to have... a boilerplate :D
I mean by that to write for all webdevelopers the stuff they are unfamiliar with (OS support, installers), so they can right away be productive with stuff they know (JS, HTML, CSS). Just wanted to spare people the pain I had to go through to have installable app, so they can just write the app, and not waste two weeks of their life on setting everything up.

And this approach turns out to be liked by people.

So.. as long as people will get the app they can install, they don't care what tool was used under the hood to produce this installer. They're just interested in their app code.

Will have a little time this week, and do my own research on electron-builder.

[dfabulich]

I think there's absolutely value in having a boilerplate built around electron-builder, or at least a wizard/installer. builder's setup steps are finicky.

[black-snow]

@szwacz can you give us a branch to work on this?

[szwacz]

@black-snow there you have it: packaging-rework

[szwacz]

And what are your impressions of electron-builder so far? I've tinkered with it a bit and my impressions are not super-awesome. I can't get simple things like app icon to work, bug? Or just the dosc are outdated?

Anyway do you have any success with it?

[black-snow]

I'm actually using it in production and it's running pretty great. Sadly I haven't yet found the time to hack on this :|

[rohit-lakhanpal]

@black-snow any chance you could try adding it on to the boilerplate? Keen to get auto-update working. Would also really love to hear your learnings/gotchas that devs need to be mindful of whilst using electron-builder in production. Thanks much.

[matiasmolleja]

And what are your impressions of electron-builder so far? I've tinkered with it a bit and my impressions are not super-awesome. I can't get simple things like app icon to work, bug? Or just the dosc are outdated? Anyway do you have any success with it?>

I tried electron-builder + electron-packager some time ago. In fact I discarded electron-boilerplate in favor of them only because of autoupdate feature.
A few weeks later I returned to use electron-boilerplate. Maybe I was doing something wrong, but I don't think so. Electron-Builder seems much more easy, and has less issues, for me at least. The only problem for me in electron-boilerplate is the lack of autoupdate. So please, think carefully and test throughtly before switching.

[McPo]

And what are your impressions of electron-builder so far? I've tinkered with it a bit and my impressions are not super-awesome. I can't get simple things like app icon to work, bug? Or just the dosc are outdated?

Anyway do you have any success with it?

Im using electron-builder and theres be no issues so far, infact its great.
I assume your placing the icon in the build folder? What OS are you using?

[black-snow]

Alright, let's start with this.

The first key-difference is that electron-builder uses different directories.

electron-builder requires (by default):

• app - contains the app-files - this is pretty much build in the boilerplate
• build - contains mostly images used for the installers - comparable to resources
• output - holds the releases - comparable to releases

By default electron-builder has no tasks that run before building the installers. We'll most probably want to keep some of our tasks (things like rollup, babel-stuff, ....).

On one hand I think it'd be good to stick to electron-builder's defaults. On the other hand that would mean that what's build in the boilerplate now would become app and that's quite counterintuitive. I'd suggest we keep the boilerplate-meaning of app and build and point electron-builder to the build directory (for our build actually contains the "built" application).
That means that we'll have to drop electron-builder's build directory, too. We can either stick to resources or be more explicit and call it installer-resources or something like that.

Rewriting the paths for those directories is a piece of cake and can be achieved via the package.json (see https://github.com/electron-userland/electron-builder/wiki/Options#directories).

---

Another question is what to choose as default build targets.
I don't think that Squirrel is a good default for there's lots of things to set up and have in mind (creating an endpoint somewhere, adding the upstream URL, adding empty RELEASES, handling the events, ...). I don't know what's to be done for mas releases for I haven't yet done any.
For windows we have the following targets: squirrel, nsis, 7z, zip, tar.xz, tar.lz, tar.gz, tar.bz2
We could chose nsis for that's what we're doing already. However nsis was only added recently and (imho) isn't thoroughly tested yet. Also it's not using a .nsi-file (which could be good or bad ... or both).
Idk what a sensible default would be for linux, maybe just zip.

---

electron-builder will - in contrast to the boilerplate, I think - drop older releases when running npm run dist. Currently I'm backing up my releases after each build. Maybe we can automate this.

[McPo]

I second, changing the default directories, as opposed to changing the project to use the default directories.

However Id push for using Squirrel as the default. You dont need to do the auto-updating stuff and it's installers is the most straightforward no hassle approach. I'd also suggest the use of https://www.npmjs.com/package/electron-squirrel-startup to generate the shortcuts on Windows.

[szwacz]

Folders...
I don't mind to change the folders if the new naming will be more clear and intuitive than current.
app - well, kind of makes sense, built-app would be best. Then current app could be renamed to src what is also strong convention.
build - in the term electron-builder is using it makes no sense for me at all (am I missing something?)
output, releases, dist - all of those could be synonyms. Doesn't matter wich of those it will be.

Installers...
Nice thing about Squirrel is that it's installed from npm, and (I assume) have no dependencies which should be installed separatlely (NSIS is such dependency for current configuration). That makes Squrrel the best default target.

Linux...
The most used package format is deb, actually I'm very suprized that for past year no one requested rpm packaging support (second most popular when I did the reaserch some time ago, apparently not popular enough). Zip is no good for linux as far as I know the platform. Deb will do the job.

[develar]

what to choose as default build targets.
We could chose nsis for that's what we're doing already. However nsis was only added recently and (imho) isn't thoroughly tested yet.

NSIS outperforms Squirrel.Windows in all aspects, only electron-userland/electron-builder#529 is the reason why nsis is not yet set as default. It will be fixed soon (month?).

isn't thoroughly tested yet.

5.12.1 should be production ready. But yes, it is not yet time-proven.

Idk what a sensible default would be for linux, maybe just zip.

Consider use AppImage target (http://appimage.org, electron-userland/electron-builder#504 (comment)). It will be default Linux target in the next major release of electron-builder.

(I assume) have no dependencies which should be installed separatlely (NSIS is such dependency for current configuration

No, you don't need to instal NSIS — pre bundled for macOS, Linux x64 and Windows.

[develar]

Currently I'm backing up my releases after each build. Maybe we can automate this.

You can file issue about it. Why electron-builder does it? Because if we need to build delta patch, we must use valid previous version. No one can guarantee that file in your dist is the same as in the download server.

[develar]

FYI: to build Linux on Windows we provides docker image — https://github.com/electron-userland/electron-builder/wiki/docker (yes, it is for advanced users).

[black-snow]

@develar hey there, thanks for checking in
So NSIS will get auto updates, too? Great. Could you please explain in which ways NSIS outperforms Squirrel? NSIS seems to be more configurable.

Switching our default from squirrel to nsis shouldn't be a big deal once nsis is ready (with auto updates).
Sounds like we should just default to electron-builder's defaults ;)

@develar Maybe I'll file an issue. I see why electron-builder throws away the most previous build but it seems to drop everything from the output directory. Let's assume I have versions 0.0.1, 0.0.2 and 0.0.3. When I npm run dist a 0.0.4 electron-builder will drop everything from the output dir, download the 0.0.3 again and build the 0.0.4, right? Why not just download what it needs and keep all other things in place? Maybe I'm wrong and this isn't the behaviour (anymore).

[develar]

Sounds like we should just default to electron-builder's defaults ;)

Yes, but until AppImage is not default (it requires major version update — don't want to do it right now), I suggest to explicitly set Linux target to AppImage.

Could you please explain in which ways NSIS outperforms Squirrel?

electron-userland/electron-builder#472 (comment)
electron-userland/electron-builder#472 (comment)
ia32 and x64 in one installer.

NSIS just much better.

Why not just download what it needs and keep all other things in place?

For what do you need old artifacts?

[black-snow]

@develar thanks again for your reply. I'll file an issue so that we don't "pollute" the discussion here.

[szwacz]

@develar welcome author of electron-builder :) Thank you for all your insider info. Very helpful stuff.

Question to discussion participants. Has anyone something done already about this boilerplate and electron-builder? I hope to have some time to work on it this weekend, but would be shame to re-doing steps already done by some of you folks.

[fedegratti]

Hi guys, I was following this issue since it started and I guess I can help now.
@szwacz I could build a boilerplate using gulp and electron-builder. I will do an example and post here tomorrow.

[fedegratti]

Here it is: https://github.com/fedegratti/electron-boilerplate/tree/add_eletron-builder
I just added electron-builder as devDependencies, set "build" and "directories" options and added "release-electron-builder" command to run "guld build" and then "build".

Some considerations:

1. build.win.icon has to be set.
2. The default directories.buildResources path is "build" so we need to change it because gulp already uses build folder.
3. In directories.app we set "build" folder because we need the project already built.

I hope it helps!

[szwacz]

Packaging with electron-builder works on branch https://github.com/szwacz/electron-boilerplate/tree/packaging-rework
Indeed the migration was easier than I thought. And indeed windows build with NSIS... just works.

Still icons for linux doesn't work. Do I have to have all those icon resolutions?
24x24.png
32x32.png
48x48.png
64x64.png
128x128.png
256x256.png

[develar]

And indeed windows build with NSIS... just works
build.win.icon has to be set.

build.win.icon is required only for Squirrel.Windows (shame!)

Still icons for linux doesn't work. Do I have to have all those icon resolutions?

No. If you auto transform macOS icns doesn't work for you, in the build/icons you can put any number of PNG files ( filename must contains size (e.g. 32x32.png))). electron-userland/electron-builder#593 (do not require icons).

[black-snow]

@szwacz I think we can drop our install/rebuild native tasks - worked out of the box using electron-builder.
The custom NSIS script can be dropped, too (develar is working on this but I guess he'll provide a template then, anyway).
Will file two seperate PRs.

[szwacz]

@black-snow as I said in the PR I believe we still need this install/rebuild native modules.
Yep, installer.nsi script was dumped (so did setup-banner.bmp since is used in "boring" installer which isn't used here).

[black-snow]

@develar I feel like when I was using electron-builder native modules were handled automagically in dev mode as well in the releases. Can you confirm this? I guess "postinstall": "install-app-deps", was the key.

[develar]

"postinstall": "install-app-dept"

This required only to install app deps when you execute npm install in the root project dir. To avoid cd app && npm install.

electron-builder doesn't use it on build — if two-package.json structure is used (electron-boilerplate uses it), we call npm rebuild in any case (all required env are configured properly — https://github.com/electron-userland/electron-builder/blob/master/src/util/util.ts#L24) (not npm install — it is broken and must be not used to rebuild dependecies).

[szwacz]

Awesome, so boilerplate codebase shrinks more and more.

[black-snow]

I'll get to use the boilerplate/ builder-branch on my current project so I can gather some experiences on what might be missing over the next weeks ;)
Hope that NSIS auto-update + custom script will be available soon.

Are we missing anything else for now?

[szwacz]

Great, but this code actually already has feature-set of previous version of the boilerplate, so can be released. And I will do it after final round of testing on weekend. Then we can move to auto-updates.

[mattzuba]

Not sure of a better place to ask this question, and I think this issue seems most appropriate. I have an existing project I've been using the original boilerplate with (as of about a month ago). How easy/difficult will it be to migrate to the updated boilerplate that works with builder? I've made a few customizations to the scripts and such from the boilerplate, but nothing that I couldn't reworked or even eliminated based on a new structure.

[black-snow]

@mattzuba greatly depends on how much you've customized your setup I'd say. Your stuff inside app should not need to be touched. If you depend on custom NSIS scripts you'll have to wait for electron-builder to support this. If there's nothing too fancy in your build/release process the transition should be smooth :)

[mattzuba]

Great, thanks! I only customized the NSIS script a tiny bit, but not much, nothing that I can't figure out how to do without it. Looking forward to seeing this integration complete!

[szwacz]

This work just landed in the master branch. Thank you all for help!

[black-snow]

Thumbs up