Would be awesome to see an AppImage build from this PR.

This pr include binary for AppImage and deb.

Unfortunately the build currently fails...

On Mac and Windows, it seems like some test taking too much time. On linux, it seems test failed.

Now that they merged #2271, what does this mean for this PR? How can we get AppImages given that #2271 was merged?

This pr replace electron-packager with electron-builder. You can directly build linux binary with npm task.

I know but if they have merged the other PR then it seems like they want to use electron-packager rather than electron-builder.

@gengjiawen please let me know when you'd like me to look at this.

I'd like to see if we can leverage the electron-packager output and one of the existing installer projects (electron-installer-debian, electron-installer-redhat and electron-installer-flatpak are mentioned in the docs) before we consider switching over to electron-builder - we've invested a lot here, and I'd hate to break existing things unnecessarily.

Also, please have a look at shiftkey#1 which is a working build and test setup for Desktop Linux on Travis - I'd like to get those incorporated sooner rather than later, so I might put together a PR for that this week on top of this discussion.

My main consideration switch to electron-builder is that:

• It is simple to config multi-platform build.
• Use appveyor and travis-ci to automatically upload binary to Github Release.
• Very convenient to include static files.

I am not that familar with electron-packager, if we can do the linux build with electron-packager without much change, I am open to it :)

Can you also create a snap?

@shiftkey I am not familiar with the source code, for now I still can't let npm run test:unit get passed. Any idea why ?

@Plasmmer I already made three linux binary type, do you have a strong reason why snap need supported ?

Snap is the future of Ubuntu packages.

I still can't let npm run test:unit get passed. Any idea why ?

@gengjiawen it looks like npm run test:unit completes, but the next step npm run test:integration doesn't complete, and I think this is because of the changes to packaging.

For example, the launch test is trying to use the contents of the out directory which probably doesn't exist now. It's probably the same for the other environments.

But i fix the path in recent commit, maybe it's something else. I need to setup a linux environment in my local machine.

But i fix the path in recent commit, maybe it's something else.

Yes, you've updated the path. But if electron-packager is outputting installers rather than the loose files that were previously living in out then the integration tests are still going to fail.

@gengjiawen it is possible to use electron-builder together with electron-packager to generate e.g., the AppImage: https://github.com/electron-userland/electron-builder#pack-only-in-a-distributable-format

I think maybe it missing the git directory, but I am wrong. There is something still missing.

I find it, I missed the package.json.

But I still get no clue why appveyor hanged after test:unit.

Is there any status on this pull request?

@gengjiawen apologies for the delay in reviewing this. I'm worried about all of the changes underway here and how they affect the other platforms (currently Appveyor fails on linting, the latest Circle build fails on a unit test, and the Travis integration test fails).

Now that we have first-class Travis support for Linux working in #2808, I've been throwing some spare cycles at how easily we can add packaging for whatever platforms we need. I know you are a fan of electron-builder, and I still don't like how much we have to depend on electron-builder, but you can see my progress over here: shiftkey#2

Here's the package we can generate currently on Travis:

I'll outline why I want to continue down this path over this migration to electron-builder:

• it doesn't currently require any changes to the contents under the app directory to support it. This might need to occur in the future as we uncover things that are platform-specific, and that's okay. But for now, we can keep things clean.
• It keeps the build, test and package steps composable, rather than the unified approach of electron-builder
• It integrates nicely with our how we package things for macOS and Windows, and gives us hooks to customize things if we need to.

I can see there's a number of merge conflicts in this PR due to the pace of changes with packages and environment changes, so I want an approach that makes it easier for forks like yours to keep up while we figure out what our official support looks like. If I get these changes reviewed and merged, would they help with the heavy lifting of maintaining your fork of Desktop?

If you have any doubt, just leave this be. I will maintain this when I got time :)

Closing in favour of #2993