Current state of Electron / meteor-desktop

There’s a lot of discussion here about whether meteor-dekstop should have first party support, or if PWA has eliminated that. But putting that aside, the fact is that right now I need to bundle with Electron because I have a client who needs an app to have local filesystem access. So unless there’s another way of reading/writing to local files, I’m asking for help in the quickest way of getting Electron working…

That thread also includes people who’ve done it, but say that it’s difficult. Are any of you wiling to share a quick bullet list of what to do? I’d like to build in linux, or possibly windows. Not mac. Deployment target it windows. @larry, @efrancis, @linegel, @ajaay? Is hot-code-push possible?

Thanks for your help - I’m sure others would benefit from an up-to-date set of instructions also!

2 Likes

To follow up on this, I went ahead and followed the instructions and it all just worked! Including HCP.

Now I have a single code-base giving me web, android, iOS and multi-platform desktop!

My client is very happy with the new possibilities this opens up, so I have a lot of work to do adding new features.

5 Likes

Awesome @wildhart! Would you want to write about this at all? The Meteor Community has recently been approved for a free open source GitBook account where we are starting to create community driven GitBooks that can have a longer life & easier maintenance cycle than some other formats that have been used in the community before.

I know I got pretty excited about PWAs on the other thread for desktop & mobile, but I really believe we need Meteor to have a solid supported path to Electron and other options too.

If you haven’t used a GitBook before, it’s the fastest & easiest way to create really great looking docs, guides, books, etc. and keep it in sync with a GitHub repo of your own. I’ve now tested this out and started to create some really simple guidelines for the community that will work really well!

Check out the starter GitBook Guide here: https://meteorjs.gitbook.io/meteor-open-source-gitbooks-guide/

You could have your own GitBook that is free forever to write things that might help the community and also probably write about some of your packages :package: you’ve made because they look really nice!

I’ve seen you share enough knowledge here on the forum to put you in the firm Expert class, so it would be my joy to make it easier for you to share & maintain amazing stuff.

The goal is to give people spaces to write solid, maintainable docs, & guide that might even one day be able to be handed off to the community if in the long run theoriginall creators get to busy to maintain them.

I’ll send you an invite on the Meteor Slack :sunglasses:

1 Like

Hi @mullojo, thanks for your kind words.

Much as I would love to help document what I’ve done (I have done previously [1 2 3] when I though it was something novel and not just following someone else’s instructions), in this case the meteor-desktop instructions were pretty much all I needed, plus a bit of trouble-shooting skill.

Also, unfortunately I don’t have any spare time at the moment - with a full time dev job, my own product plus a couple of private contracts, not to mention a family, I really don’t have enough spare time as it is! Sorry!

1 Like

Thanks for thinking about it @wildhart … We’ll be getting more & more of these books & guides into the community so feel free to add any inputs / comments along the way. Initially I think it’s good to have come individuals lead GitBook creation, but eventually I think it will be a lot of fun for contributors to add pages (sub-topics) here & there too :grinning:

That’s great to hear you’ve got it working because we’re having huge problems and it doesn’t work at all. Not only our customer but also me is on an old version but no matter what we try, HCP seems to not working and the documentation isn’t helping much.

We have seen errors on hash mismatch and also when we add new assets they cannot be found.

Examples:

[autoupdate] Download failure: Skipping downloading new version because the .desktop compatibility version have changed and is potentially incompatible (89a6788ba698360debc19e0cb84ddfb6 != 7dcbe810ebf17b8df9c4133d0ce91b7b)

[autoupdate] Download failure: failed at verifyResponse: non-success status code 404 for asset: daa405ad589d3e6a46f5c88b469d7843c3ebddc8.stats.json

[autoupdate] Download failure: skipping downloading blacklisted version: 0c059eac3a2c3516003fb8f7ecf56294ee5dfe4a

Any help is appreciated, thanks!

Yeah, I found that the HCP compatibility version was too sensitive for some reason. The hash would change with each build even if the plugin versions don’t change.

For that reason I ignore the compatibility check with:

 // .desktop/settings.json
    "desktopHCP": true,
    "desktopHCPIgnoreCompatibilityVersion": true,

This gets HCP working every time, but could mean I could get incompatibilities when I add new packages which desktop uses.

When I do add a new package I test for it at start up and if it doesn’t exist I send a message to the user and inform the user that they need to download the new version:

// .desktop/desktop.js
desktop.on('checkModules', (e, fetchId) => {
    const failed = [];

    try {
        const sendkeys = require('sendkeys');
        ...  // Setup sendKey handlers.
    } catch(e) {
        failed.push('sendkeys');
    }
    
    try {
        const PizZip = require('pizzip');
        ... // setup PizZip
    } catch(e) {
        failed.push('pizzip'); 
    }

    ...

    return desktop.respond('checkModules', fetchId, {failed});
});

Note that after disabling the incompatibility check you and your users will still have to manually install the version with the check disabled. After that HCP should work.

2 Likes