Next steps going forward?

[a4xrbj1]

@KoenLav mentioned to me that he runs the following packages with the version numbers in Production without problems:

"electron": "11.3.0",
"electron-builder": "^22.10.5",
"electron-packager": "^15.2.0",
"electron-rebuild": "^2.3.5"

How are we going forward from here?

What needs to be done to get the above packages to the lastest versions?

Shall we give a recommendation for a specific version of Meteor to use with this new Meteor-Desktop package?

Lastly, what about the large number of open issues that we left in the old repo?

In general, how can we get some fresh blood into this project with an agreed plan to go ahead? The first big step is done but to me eg it's unclear which new feature is most needed (from the Electron package) or which security update is critical but currently not addressed because it's beyond the "safe to use" version numbers that Koen posted?

[KoenLav]

The Meteor version doesn't seem to matter that much.

In terms of moving forward I think the most important thing to do is identifying the breaking changes from Electron which are conflicting with the current implementation in Meteor Desktop.

I believe we make use of:

• enableRemoteModule: true (https://www.electronjs.org/docs/breaking-changes#default-changed-enableremotemodule-defaults-to-false);
• worldSafeExecuteJavaScript: false (https://www.electronjs.org/docs/breaking-changes#default-changed-worldsafeexecutejavascript-defaults-to-true);
• contextIsolation: false (https://www.electronjs.org/docs/breaking-changes#default-changed-contextisolation-defaults-to-true);

Although I'm not sure of the latter two, which have only been changed in Electron 12.

I won't have time to invest in this for the next 2 months at least, so if someone is able to take a look earlier than that it would be much appreciated.

[a4xrbj1]

I believe we make use of:

enableRemoteModule: true (https://www.electronjs.org/docs/breaking-changes#default-changed-enableremotemodule-defaults-to-false);

This Medium article and the comment below the URL says: "We recommend moving away from the remote module."

Why do you want to use it and try to fix something that isn't recommended to use?

[KoenLav]

I don't want to, I believe we do.

[wreiske]

I would also like to discuss removing the requirement for a mobile platform, like ios or android. When I get the idea for a desktop app and run through the process of meteor create, meteor npm install desktop... I then have to spend hours messing with Android SDK getting it correctly installed and in the right paths in order to get all of these to pass:

Wouldn't it be nice to have a meteor add-platform desktop and it would do all the pre-requisites like meteor npm install --save-dev @meteor-community/meteor-desktop?

Or possibly even meteor create myapp --blaze --desktop with an additional flag for the "target" platform the project is meant for?

It requires some re-tooling with how Meteor works with mobile frameworks and generates the cordova web folders used by meteor desktop, but it may be worth it in the long run. It could even be a marketing thing, "building multiplatform desktop apps has never been easier with meteor 4.0!" ;)

[a4xrbj1]

Wouldn't it be nice to have a meteor add-platform desktop and it would do all the pre-requisites like meteor npm install --save-dev @meteor-community/meteor-desktop?

Or possibly even meteor create myapp --blaze --desktop with an additional flag for the "target" platform the project is meant for?

It requires some re-tooling with how Meteor works with mobile frameworks and generates the cordova web folders used by meteor desktop, but it may be worth it in the long run. It could even be a marketing thing, "building multiplatform desktop apps has never been easier with meteor 4.0!" ;)

To me it's more important to concentrate on getting the ElectronJS modules updated first. We're so many major versions (and thus also important security updates) behind.

Now obviously we cannot go beyond Node 14 at the moment, so that limits how far we can try to upgrade.