provide way to create "installers" (.dmg, .msi, .deb etc) about electron-packager

[malept]

@englishextra Electron Packager is fine to use by itself still, but if you need to create installers then Electron Forge is a good, ergonomic option. Particularly if you don't want to glue all the pieces together yourself.

To be clear, Electron Packager is not going anywhere. I'm still maintaining it (I just made a PR this week). It's a pretty significant dependency of Electron Forge. And it's going to stay outside of Electron Forge because, to repeat something I mentioned in a Forge ticket:

We're adhering to the Node community/UNIX convention where modules should ideally be created for one particular concept, and then meshed together in higher-level modules.

[malept]

The current recommended way to build installers (which also happens to use Electron Packager) is Electron Forge.

[havenchyk]

@malept why not electron-builder? is there any explanation?

[havenchyk]

@malept well, while init and import options are pretty interesting, I still can't see the reason why you have created new product from the scratch. electron-builder is pretty mature and yes, @develar is the only maintainer, but he made this product as awesome as possible.

If TypeScript was a problem, project could be rewritten to ES2015+ in a couple days, btw @develar already solved a lot of problems in electron-builder and provided pretty interested solutions.

Sorry for this, I know that my comment doesn't relate to electron-packager and issue, but to me this situation looks terrible. Facebook hunted a lot of developers from other concurented products to allow them to do awesome thing inside Facebook, but electron community just killing electron-builder. To my mind you and other developers from community ignored the problem with building application for a quite long time (It was painful experience before electron-builder, really), now you decided to kill electron-builder or provide "choice" (here should go image about 14 standards), it's unacceptable, IMO.

[MarshallOfSound]

@havenchyk In the entire time I have contributed to Open Source I have never seen a project have to defend the reason for its existence. That said, unfortunately based on where you seem to be taking this discussion, this will be the first.

I still can't see the reason why you have created new product from the scratch.

This is not the case, as @malept said in his original response we use community maintained modules to provide most if not all of forges functionality. All forge actually does is wire everything up in an easy to use way. Actually we even explain this in one of the first lines of our README.

Electron Forge unifies the existing (and well maintained) build tools for Electron
development into a simple, easy to use package so that anyone can jump right in
to Electron development.

To my mind you and other developers from community ignored the problem with building application for a quite long time

I'm not sure how to respond to this, are you somehow under the impression that @malept or I or any other community member was under an obligation of some kind to provide a tool such as -builder or -forge because to clarify, we were not. The original methods for building an Electron application worked and weren't actually too difficult to understand, lots of the issues people were having were either due to out of date guides (Electron tools moves very quickly) or simply a lack of experience with node.js in general. While I can agree that -builder simplifies the process for many people it does so in a way that people (@malept and I included) do not feel is the best way for the Electron community and we were sure that we could improve on it in a new tool; as such we created -forge.

it's unacceptable, IMO.

I'm confused as to what you think is unacceptable, the fact that we made -forge or the fact we didn't provide a solution to the building problem for a long time. These two issues you raise actually contradict each other. I would however like to point out the Electron CoC in particular.

* Being respectful of differing viewpoints and experiences
* Gracefully accepting constructive criticism
* Focusing on what is best for the community

We are of the firm belief that electron-forge is the best direction for the electron-packager and electron community. We understand that some people will disagree with our ideas, opinions or even our code but we sincerely hope that you can accept our reasons and possibly even see what we are trying to achieve with -forge.

[eveningkid]

+1, such a tool would be appreciated.

[jenslind]

Existing tools for .dmg creation:
https://github.com/andreyvit/create-dmg
https://github.com/LinusU/node-appdmg

[malept]

It would be nice if the installer creation could be run from one OS (as is currently the case with electron-packager), then one could use CI to automatically generate them for releases. Unfortunately, after searching for cross-platform support for creating .dmgs, it appears that results are mixed.

[nickdesaulniers]

One of the ways I did this manually was from here. These installers are much more user friendly. Would love to be able to generate a .dmg or .msi file.

[nickdesaulniers]

In OSX, diskutil can be run from the command line, so we could write a wrapper that shells out the commands. Unfortunately, this approach wont be portable to Win/Linux.

[stefanjudis]

We wrote automated installer generators for windows and macos last week.
Can probably provide a PR at the weekend, if wished.

[sbruchmann]

@stefanjudis Definitely. ;)

[nickdesaulniers]

if wished.

I can haz?

[max-mapper]

@stefanjudis i'd rather have the installer code live in another tool, and not make this module any bigger (its already getting bloated). but sharing your code would be much appreciated :)

[stefanjudis]

@maxogden

Fair enough. Currently it's in a private company repo. But we sure'ly can transfer it.
Any name suggestions for the project then? I see electron-packager is already taken. :)

[nickdesaulniers]

electron-installer
electron-installer-generator
electron-distributor
electron-bundler
electron-builder
electron-emitter
electron-beam-cannon

[stefanjudis]

Here we go. Will ping you guys on the weekend. :)

https://github.com/stefanjudis/electron-builder

Made in company working hours so it will be placed here. :)

-> https://github.com/loopline-systems/electron-builder

[eveningkid]

I'll look forward, then. Thank you stefan!

[stefanjudis]

Will tackle it tomorrow. :)

Arnaud [email protected] schrieb am So., 24. Mai 2015 01:50:

I'll look forward, then. Thank you stefan!

—
Reply to this email directly or view it on GitHub
#33 (comment)
.

[LinusU]

Hi,

I have built appdmg in Node.js which produces lovely looking dmg-images. We are currently tracking cross-platform here: LinusU/node-appdmg#14 (comment)

I think it certainly possible to get it working but there will be a lot of man hours behind it. We do create the .DS_Store files from scratch instead of using Apple Script which most other solutions do. The only large thing that is left is replacing hdiutil, for that we need something that writes an HFS+ file system which might be a bit complicated, although there are open source solutions in the wold.

appdmg is used as such from Node:

var appdmg = require('appdmg');
var ee = appdmg({ source: 'test/appdmg.json', target: 'test.dmg' });

ee.on('progress', function (info) {

  // info.current is the current step
  // info.total is the total number of steps
  // info.type is on of 'step-begin', 'step-end'

  // 'step-begin'
  // info.title is the title of the current step

  // 'step-end'
  // info.status is one of 'ok', 'skip', 'fail'

});

ee.on('finish', function () {
  // There now is a `test.dmg` file
});

ee.on('error', function (err) {
  // An error occurred
});

Instead of passing source: 'file-path' you can also pass basename: 'dirname', specification: { ... } so it should be good to go 👍

[havenchyk]

Guys, could anyone clarify, what's the recommended way right now?

AFAIK, for windows it's better to use grunt-electron-installer (official?)
for mac is it ok to use appdmg?

Another question:
Should we use same OS as a target? I mean windows to make windows installer, mac - for mac.

@maxogden could you please share your thoughts?
@stefanjudis do you use in electron-builder the same way to make windows build as grunt-electron-installer?

[malept]

Guys, could anyone clarify, what's the recommended way right now?

A link to electron-builder was added to the README a couple of months ago. Take that as you will. electron-builder also uses appdmg to create .dmg files.

Should we use same OS as a target? I mean windows to make windows installer, mac - for mac.

DMG creation does not currently work on any other OS than OSX. (See: LinusU/node-appdmg#14.) Otherwise, a Windows installer can be created on any (supported) platform. (See electron-builder's README.)

[havenchyk]

@malept but is there any recommended way? sorry if it's offtop

[malept]

@havenchyk it depends on what you mean by "recommended". I personally use electron-builder for Windows installers. Need to figure out how to generate OSX DMGs with it too, even though I don't personally have a copy of OSX.

In fact, since electron-builder exists and is mentioned in the README, I'm going to close this issue. Per @maxogden, providing installers is outside the scope of electron-packager.

[havenchyk]

@malept sure, thanks for your answers here. If electron-builder is in the readme, it's enough for me

[develar]

electron-complete-buidler can produce installers (auto-update ready, including Linux deb package), sign it on CI server and publish to GitHub releases.

[stefanjudis]

Ouch. :(

@develar Why not contributing to electron-builder?

[develar]

@stefanjudis Originally, electron-builder was used under the hood.

But then I realized, that I need squirrel-windows installer to build auto-update ready windows app. So, now I use windows-installer to produce windows artefact. It is the main reason why electron-builder is not used.

So, electron-builder was used only to produce DMG. But... why I should use electron-builder if appdmg does the same? So, in the end, electron-builder was removed.

[stefanjudis]

that I need squirrel-windows installer

This will be implemented soon when this https://github.com/electronjs/windows-installer is officially released and we already have a filed issue for that.

Linux installers are also included now.

The only thing that makes me sad, is the creation of a concurrent project which has several contributors and already gained some traction.
Contributing to an existent project doesn't increase noise for users ( like the confusion for windows installers - where I had to scan 5 projects that do the same ), reduces number of concurrent projects and helps existent projects.

As we'll implement the official squirrel thingy we'll end up with two similar projects. :(

Never the less. Good luck with that one.

[develar]

@stefanjudis To be clear — electron-complete-builder is not yet another tool to produce installers, but tool to combine all existing tools to "just publish my electron app".

As we'll implement the official squirrel thingy

In this case I will just switch back to use electron-builder again as before.

Do you want to integrate https://github.com/develar/electron-complete-builder#code-signing, https://github.com/develar/electron-complete-builder#build-version-management and https://github.com/develar/electron-complete-builder/wiki/Publishing-artifacts into electron-builder?

I ready to create pull requests and do so (e.g. #251, #255). But I think we should follow Unix Philosophy — Do one thing and do it well.

Do you agree with me or I am wrong? Sorry, but I don't want to have gigantic package.json as you suggest — https://www.npmjs.com/package/electron-builder#how-we-use-it-so-far See my app — https://github.com/develar/onshape-desktop-shell/blob/master/package.json Only one line "release": "npm run compile && build" and app published to GitHub releases.

[stefanjudis]

@develar

Thanks for clarification and I'd love to collaborate. :) Let's move the discussion over to our projects to not create more noise here. :)

[malept]

There are several reasons for recommending Electron Forge:

• It's a better option for developers starting out or creating new Electron apps (just run electron-forge init and it will create a new skeleton Electron app).
• You can import existing Electron apps and it will convert it to the best of its ability (electron-forge import).
• Electron Forge has more than one co-maintainer (bus factor), some of whom are quite prolific in the Electron community.
• Given that this is an issue in the Electron Packager repository: Electron Forge uses Electron Packager, electron-builder has not for quite some time.
• In addition to Electron Packager, Electron Forge uses several community-created modules to accomplish much of its tasks, and works with upstream to handle any relevant features/bugs reported in the Forge issue tracker. This also means that the surface area of Forge is much smaller than electron-builder.

There's a bunch of other reasons but they're not particularly relevant to this issue.

[englishextra]

@havenchyk electron-builder kamikadzed itself. Orchestrating turned out not to be enough. NSIS was rejected. Couldn't build IOS installers on Windows machines (I remember lots of issues notifying me via email subscription), and RPM's had to be rpmbuilt manually on Linux. So what it was for then.
@MarshallOfSound electron-packager is condemned, and sooner or later I should and need to learn the -forge tool?

Good luck, At least, thanks for electron-packager doing its work, as for installers, I could make it on my own.

[englishextra]

@malept electron-packager is my only concern. The rest will be worked out. Yeah-yeah I wouldn't be happy if it is absorbed by some -forge monster. Thanks for your work. Good tool.

[develar]

@havenchyk electron-builder provides a lot of features that are not covered by forge or any other module. And unlikely will be covered. And targets. And can be used to just pack into distributable format already packed app. Forge is just another user module, not official electron tool.

Star trend and download counts show what user wants to use. In any case such situation is good for user — competition.

In any case electron-builder is going to be splitted into several packages (it is not required for users, because electron-builder is a lightweight and no need to reduce external npm deps (only archiver that is used only for squirrel.windows)).

[havenchyk]

@MarshallOfSound don't get me wrong.

I really appreciate all your and community work on forge and even thank you for so well explained answer.

There is no any concern about creating new package with "electron way", it's completely fine for OSS.

My main concern was that you came up with new solution (forge) and marked it as a "recommended" way. Because with that you can kill another good product.

Anyway I see your and @malept points, so good luck with it and again thanks for your work.

I think this dicussion can be closed 😄