The fork maintains full API compatibility with the original while providing modern, secure, and actively maintained codebase for building Electron-powered Meteor applications.
Happy to help. This package is instrumental to our users app, hence I will keep updating it to stay on the newest ElectronJS versions and also make sure that we’re not having outdated dependencies.
However, I won’t support older versions of Meteor. For that use case the “old” repo is the correct one.
Not really, I have my fork. To me, there’s no purpose for it, I’ve done already all the work and while not everyone will agree with my restrictions to use the latest MeteorJS version with my fork, that’s the best way going forward for me to ensure this package isn’t falling behind the latest Meteor versions or ElectronJS.
WarningWe recommend setting desktopHCP to false in your settings.json. See the important limitations section below.
Applications produced by this integration are fully compatible with Meteor’s hot code push mechanism. The faulty version recovery is also in place - more about it here. You can configure the timeout via webAppStartupTimeout field in settings.json.
Versions are downloaded and served from userData directory. There you can find autoupdate.json and versions dir. If you want to return to first bundled version just delete them.
You can also analyze autoupdate.log if you are experiencing any issues.
Hot code push does not cover rspack-bundled code
Important — Read before enabling desktopHCP
If your Meteor app uses rspack (Meteor 3.x default bundler), HCP has fundamental limitations that make it unreliable for production use. We strongly recommend setting "desktopHCP": false in your settings.json.
Why HCP does not work with rspack builds:
Rspack code is not delivered by HCP. HCP downloads the Meteor web.browser manifest and its assets (packages, app.js, global-imports.js). However, rspack-bundled application code (__rspack__/client-rspack.js, build-chunks/*) is injected into the Electron build by meteor-desktop at build time — it is not part of the Meteor manifest and therefore never downloaded by HCP. This means the majority of your UI code, routes, components, and styles will remain at the version that was embedded when the app was built, regardless of how many HCP updates are applied.
HCP requires the production server to already be deployed. HCP fetches the manifest from ROOT_URL/__browser/manifest.json — your live production Meteor server. For HCP to pick up your commits, you must first deploy the new code to production. If you’re deploying anyway, building and distributing a new desktop app version is more reliable.
HCP adds startup complexity for zero practical benefit. With desktopHCP enabled, the autoupdate module runs version resolution, fallback logic, a startup timer, and compatibility version checks on every app launch. Each of these is a potential failure point. With rspack-bundled code not being covered, this complexity delivers no meaningful update capability.
Version mismatches cause silent failures. If HCP downloads a new Meteor web.browser bundle but the rspack bundle remains at the old version, the two can be incompatible — leading to runtime errors, missing templates, or broken UI that is difficult to diagnose.
Recommended configuration:
{ “desktopHCP”: false }
With HCP disabled, the app always uses the embedded meteor.asar bundle. The startup path becomes deterministic: embedded bundle → local server → load. To ship updates, build and distribute a new version of the desktop app.
Updated Dependencies (13+ packages modernized)
GitHub: https://github.com/a4xrbj1/meteor-desktop
