meteor-desktop
Advanced tools
Build desktop apps with Meteor & Electron. Full integration with hot code push implementation.
Travis 
AppVeyor
CircleCI
This is a complete implementation of integration between Meteor and Electron aiming to achieve the same level of developer experience like Meteor gives.
To make it clear from the start, this is a desktop client - it is just like your mobile
clients with Cordova - but this is for desktops with Electron. It also features a full hot code
push implementation - which means you can release updates the same way you are used to.
1.4*1 you can always build with --server-only if you do not want to have mobile clients, you do not actually have to have android sdk or xcode to go on with your project
cd /your/meteor/app
meteor npm install --save-dev meteor-desktop
# you need to have any mobile platform added (ios/android)
meteor --mobile-server=127.0.0.1:3000
# open new terminal
npm run desktop -- init
npm run desktop
# or in one command `npm run desktop -- --scaffold`
--help// Assumming you have a `desktop` script in npm scripts that equals to "meteor-desktop"
Usage: npm run desktop -- [command] [options]
Commands:
init scaffolds .desktop dir in the meteor app
run [ddp_url] (default) builds and runs desktop app
build [ddp_url] builds your desktop app
build-installer [ddp_url] creates the installer
just-run alias for running `electron .` in `.meteor/desktop-build`
package [ddp_url] runs electron packager
init-tests-support prepares project for running functional tests of desktop app
Options:
-h, --help output usage information
-b, --build-meteor runs meteor to obtain the mobile build, kills it after
-t, --build-timeout <timeout_in_sec> timeout value when waiting for meteor to build, default 600sec
-p, --port <port> port on which meteor is running, when with -b this will be passed to meteor when obtaining the build
--production builds meteor app with the production switch, uglifies contents of .desktop, packs app to app.asar
-a, --android force adding android as a mobile platform instead of ios
-s, --scaffold will scaffold .desktop if not present
-i, --ignore-stderr [string] only with -b, strings that when found will not terminate meteor build
--meteor-settings <path> only with -b, adds --settings options to meteor
--prod-debug forces adding dev tools to a production build
--ia32 generate 32bit installer/package
--all-archs generate 32bit and 64bit installers
--win generate Windows installer
--linux generate Linux installer
--mac generate Mac installer
-d, --debug run electron with debug switch
-V, --version output the version number
[ddp_url] - pass a ddp url if you want to use different one than used in meteor's --mobile-server
this will also work with -b
--build-meteorIf you just want to build the desktop app, package it or build installer without running the
Meteor project separately you can just use -b and all will be done automatically - this is useful when
for example building on a CI etc.
--androidWhen there is no mobile platform in the project and -b is used, mobile platform is added
automatically and removed at the end of the build process. Normally an ios platform is added
but you can change this to android through this option.
Desktop and Module - communication between Meteor and Electron
If you have ever been using any Cordova plugins before you will find this approach alike. In Cordova every plugin exposes its native code through a JS api available in some global namespace like cordova.plugins. The approach used here is similar.
In Electron app, there are two processes running along in your app. The so-called main process and renderer process. Main process is just a JS code executed in node, and the
renderer is a Chromium process. In this integration your Meteor app is being run in the
renderer process and your desktop specific code runs in the main process. They are
communicating through IPC events. Basically, the desktop side publishes its API as an IPC event
listeners. In your Meteor code, calling it is as simple as Desktop.send('module', 'event');.
Code on the desktop side is preferred to be modular - that is just for simplifying testing and
encapsulating functionalities into independent modules. However, you do not have to follow this style, there is an import dir in which you can structure your code however you want. The basics of an Electron app are already in place (reffered as Skeleton App) and your code is loaded like a plugin to it.
Below is a high level architecture diagram of this integration.
or how hacky is this?
The main goal was to provide a non hacky integration without actually submitting any desktop
oriented pull request to Meteor.
The whole concept is based on taking the web.cordova build, modifying it as little as possible
and running it in the Electron's renderer process. The current cordova integration
architecture is more or less conceptually replicated.
Currently the only modification that the mobile build is subjected to is injecting the Meteor.isDesktop variable.
To obtain the mobile build, this integration takes the build from either
.meteor/local/cordova-build (version < 1.3.4.1) or from .meteor/local/build/programs/web.cordova.
Because index.html is not present in the web.cordova directory and program.json lacks
version field, they are just downloaded from the running project.
Electron app is structured?The produced Electron app consists barely of 4 files:
app.asar - bundled Skeleton App and node_modules (including all your dependencies from
settings.json and modules)meteor.asar - your Meteor app bundled to an .asardesktop.asar - processed contents from .desktoppackage.json - Electron requires a package.json to be presentWhile developing, the app is not asared so you can take a closer look at the Skeleton that is
produced by this integration. You will find it in the .meteor/desktop-build directory.
app.on('ready')?The app.on('ready') is handled for you by the Skeleton app, but that does not mean you can
not hook into it. Basically, code that is in the constructor of .desktop/desktop.js and
all constructors of your modules is executed while being inside ready. Remember that is always
a good practice not to do time consuming tasks inside the constructors but instead delay those tasks
by hooking to beforeDesktopJsLoad, desktopLoaded or afterInitialization on the eventsBus.
If you have not run the example from the Quick start paragraph, first you need to scaffold a
.desktop dir in which your Electron's main process code lives.
To do that run: (assuming npm install --save-dev meteor-desktop did add successfully a desktop
entry in the package.json scripts section)
npm run desktop -- init
This will generate an exemplary .desktop dir. Lets take a look what we can find there:
.desktop
├── assets # place all your assets here
├── import # all code you do not want to structure into modules
├── modules # your desktop modules (check modules section for explanation)
│ └── example # module example
│ ├── index.js # entrypoint of the example module
│ ├── example.test.js # functional test for the example module
│ └── module.json # module configuration
├── desktop.js # your Electron main process entry point - treated like a module
├── desktop.test.js # functional test for you desktop app
├── settings.json # your app settings
└── squirrelEvents.js # handling of squirrel.windows events
Tak a look into the files. Most of them have meaningful comments inside.
Some files are described more in detail below..
This is the main configuration file for your desktop app. Below you can find brief descriptions of the fields.
| field | description |
|---|---|
name | just a name for your project |
version | version of the desktop app |
projectName | this will be used as a name in the generated app's package.json |
devTools | whether to install and open devTools, set automatically to false when building with --production |
devtron | check whether to install devtron, set automatically to false when building with --production, more |
singleInstance | sets the single instance mode - more |
desktopHCP | whether to use .desktop hot code push module - more |
desktopHCPIgnoreCompatibilityVersion | ignore the .desktop compatibility version and install new versions even if they can be incompatible |
desktopHCPCompatibilityVersion | allows to override .desktop compatibility version |
squirrel.autoUpdateFeedUrl | DEPRECATED url passed to autoUpdater.setFeedUrl, more |
squirrel.autoUpdateFeedHeaders | DEPRECATED http headers passed to autoUpdater.setFeedUrl |
squirrel.autoUpdateCheckOnStart | DEPRECATED whether to check for updates on app start |
rebuildNativeNodeModules | turn on or off recompiling native modules, more |
webAppStartupTimeout | amount of time after which the downloaded version is considered faulty if Meteor app did not start - more |
exposeLocalFilesystem | turns on or off local filesystem exposure over url alias, more |
exposedModules | array of module names, exposes any renderer modules in Desktop.electron space, i.e. list webFrame here to acess it via Desktop.electron.webFrame in Meteor project code |
showWindowOnStartupDidComplete | normally, main window appears after Chromes did-stop-loading event, set this to true if you want to depened on Meteor's startupDidComplete event |
window | production options for the main window - see here |
windowDev | development options for the main window, applied on top of production options |
uglify | whether to process the production build with uglify |
plugins | meteor-desktop plugins list |
dependencies | npm dependencies of your desktop app, the same like in package.json, only explicit versions are supported - check here |
linkPackages | array of packages names you want to link (runs npm link <packageName> for every package listed) |
packageJsonFields | fields to add to the generated package.json in your desktop app |
builderOptions | electron-builder options |
builderCliOptions | specify additional electron-builder CLI options e.g for publishing artifacts |
packagerOptions | electron-packager options |
extract | array containing dependencies that should not be packed into asar (should not be needed as there is an automatic algorithm that will exclude all dependencies containing binary files) |
You can use _windows, _osx, _linux properties to set additional settings for different OS.
The default settings.json is already using that for setting a different window icon for OSX.
Only explicit versions are supported to avoid potential problems with different versions being
installed. It is no different from Meteor because the same applies to adding Cordova plugins.
You can however use a local path to a npm package - and that will not be forbidden. You need to keep track what has been distributed to your clients and what your current code is expecting when releasing a HCP update.
The desktop.js is the entrypoint of your desktop app. Let's take a look what references we
receive in the constructor.
/**
* @param {Object} log - Winston logger instance
* @param {Object} skeletonApp - reference to the skeleton app instance
* @param {Object} appSettings - settings.json contents
* @param {Object} eventsBus - event emitter for listening or emitting events
* shared across skeleton app and every module/plugin
* @param {Object} modules - references to all loaded modules
* @param {Object} Module - reference to the Module class
* @constructor
*/
constructor({ log, skeletonApp, appSettings, eventsBus, modules, Module })
Some of the references are describe in detail below:
skeletonAppThis is a reference to the Skeleton App. Currently there are only two methods you can call.
isProduction - whether this is a production build
removeUncaughtExceptionListener - removes the default handler so you can put your own in place
eventsBusThis is just an EventEmitter that is an event bus meant to be used across all entities running
in the Electron's main process (.desktop). Currently there are several events emitted on the
bus by the Skeleton App that you may find useful:
| event name | payload | description |
|---|---|---|
unhandledException | emitted on any unhandled exceptions, by hooking to it you can run code before any other handler will be executed | |
beforePluginsLoad | emitted before plugins are loaded | |
beforeModulesLoad | emitted before internal modules and modules from .desktop are loaded | |
beforeDesktopJsLoad | emitted before desktop.js is loaded | |
beforeLocalServerInit | emitted before local http server starts | |
desktopLoaded | (desktop) | emitted after loading desktop.js, carries the reference to class instance exported from it |
afterInitialization | emitted after initialization of internal modules like HCP and local HTTP server | |
startupFailed | emitted when the Skeleton App could not start you Meteor app | |
beforeLoadFinish | emitted when the Meteor app finished loading, but just before the window is shown | |
loadingFinished | emitted when the Meteor app finished loading (also after HCP reload) | |
windowSettings | (windowSettings) | emitted with the settings that will be passed to BrowserWindow constructor - if needed the object can be modified in the event handler to override window settings from settings.json |
windowCreated | (window) | emitted when the BrowserWindow (Chrome window with Meteor app) is created, passes a reference to this window |
newVersionReady | (version, desktopVersion) | emitted when a new Meteor bundle was downloaded and is ready to be applied |
revertVersionReady | (version) | emitted just before the Meteor app version will be reverted (due to faulty version fallback mechanism) be applied |
beforfeLoadUrl | (port, lastPort) | emitted before webContents.loadURL is invoked, in other words just before loading the Meteor app; port - the port on which the app is served, lastPort - the port on which the app was served previously (when HCP is applied) |
beforeReload | (pendingVersion, containsDesktopUpdate) | emitted just before HCP reload |
moduleLoadFailed | (dirName, error) | emitted if a module failed to load |
Your can also emit events on this bus as well. A good practice is to namespace them using dots,
like for instance myModule.initalized.
modulesObject with references to other modules and plugins. Plugins can be found under their names i.e.,
modules['meteor-desktop-splash-screen].
Any module can be found under the name from module.json.
Internal modules such as autoupdate and localServer are also there. You can also get reference to the desktop.js from modules['desktop'] (note that the reference is also passed in
the desktopLoaded event).
ModuleClass that provides a way of defining API reachable by Meteor app - more.
Module is just an encapsulated piece of code. Usually you would just provide certain type of
grouped functionality in it. You can treat it like a plugin to your desktop app.
One important rule is that you should not import files from the outside of your module directory
as this will cause you problems when writing tests.
You can always reach to other modules through modules and you can as well add a module with
some common code or utils.
Every module lives in its own directory and has to have a module.json file. Currently there are
only four fields there supported:
name - name of your module, will be used as a key in modules objectdependencies - list of npm depsextract - list of files that should be excluded from packing into .asar (e.g. executables,
files meant to be changed etc)settings - this object is passed as settings field in the object passed to module constructorextractA little bit more about this. Files should be listed in a form of relative path to the module
directory without any leading slashes, for example extract: [ "dir/something.exe" ] will be
matched to .desktop/modules/myModule/dir/something.exe.
To path to your extracted files is added to your module settings as extractedFilesPath
. So your module constructor can look like this:
import path from 'path';
export default class Desktop {
constructor({ log, skeletonApp, appSettings, eventsBus, modules, settings, Module }) {
this.pathToExe = path.join(settings.extractedFilesPath, 'dir/something.exe');
}
}
WARNING: currently the path of the file is not reconstructed meaning extract: [ "dir1/something.exe", "dir2/something.exe' ] will try to put both something.exe files to the same dir and that may fail or produce inconsistent result. So the bare file names without the path must be unique.
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.
Meteor.isDesktopIn your Meteor app to run a part of the code only in the desktop context you can use Meteor.isDesktop. Use it the same way you would use Meteor.isClient or Meteor.isCordova.
Local filesystem is exposed under and url alias (similarly to Cordova integration).
This feature is disabled by default so you need to enable it first by setting
exposeLocalFilesystem in your settings.json to true. Files are exposed under
/local-filesystem/<absolute-path> url.
You can use some convenience methods:
Desktop.getFileUrl(absolutePath) - returns an url to a fileDesktop.fetchFile(absolutePath) - invokes fetch on a file's url and returns it's
Promise.desktop/assets in MeteorAssets are exposed over an url alias \___desktop\<asset-path>.
So to display an image named test.png from .desktop/assets you should use a
\___desktop\test.png url.
You can use some convenience methods:
Desktop.getAssetUrl(assetPath) - returns an asset's urlDesktop.fetchAsset(assetPath) - invokes fetch on an asset's url and returns it's
PromiseDesktop and Module - communication between Meteor and ElectronModule - desktop sideUse it to declare your API on the desktop side which you can later call from Meteor project.
this.module = new Module('myModuleName');
Documentation of the Module API - basically, it reflects ipcMain.
The only two additions are the fetch and respond methods:
(event, timeout = 2000, ...args) - like send but returns a Promise that resolves to a response, timeouts after 2000ms by default(module, ...args) - fetch but without the need specify timeout(timeout) - set the default timeout for fetch within this module(event, fetchId, ...data) is a convenient method of sending response to Desktop.fetch. The fetchId is always the second argument received in on.Desktop - Meteor sideDocumentation of the Desktop API - reflects partially ipcRenderer*.
* sendSync and sendToHost are not available
Use it to call and listen for events from the desktop side.
The only difference is that you always need to precede arguments with module name. There are two extra methods:
(module, event, timeout = 2000, ...args) - like send but returns a Promise that resolves to a response, timeouts after 2000ms by default(module, event, ...args) - fetch but without the need specify timeout(timeout) - set the default timeout for fetch(module, event, fetchId, ...data) is a convenient method of sending response to Module.fetch. The fetchId is always the second argument received in on.ipcRenderer.send - if you need to send an IPC that is not namespacedExample of send and fetch usage - here.
.desktop hot code pushexperimental!
There is an experimental support for hot code push of the .desktop directory.
It works similarly to the Meteor's builtin one. It also produces a version and
compatibilityVersion to detect whether the update can be made.
In Meteor whenever you change any of your Cordova dependencies (add/remove/change version)
you will make an incompatible change meaning that a new version will not be hot code pushed.
The same applies here. In this case your desktop dependencies are npm packages.
To make it clear, npm packages are not hot code pushed - only contents of .desktop are.
The compatibilityVersion is calculated from combined list of:
settings.jsonsettings.json.desktop/modulesmeteor-desktop (X.Y.Z - only X is taken)settings.json (X.Y.Z - only X is taken).Be aware that when it comes to linked packages (via linkPackages in settings.json) the
explicitly declared version (the one in settings.json or modules) is taken into account, not the
actual one from package's package.json. The same applies to packages added from local paths.
Generally, it is a bad idea to build production app with linked/local packages. Changes in those will not trigger a compatibility version change so you migh accidentally push a new version with desktopHCP that will not work.
Two Meteor plugins are added to your project - bundler and watcher. Bundler prepares the desktop.asar which is then added to you project as an asset.
Watcher just watches for file changes and triggers project rebuilds.
desktop.asar file will
also be
distributed to your mobile clients and cause unnecessary updates in case you only made changes in
.desktopdesktop.asar (via extract settings in a desktop module) are
not updated, nor checked for changes!.desktop which prevented startup, watcher might not work correctly and further changes
in .desktop will not trigger rebuilds, in that case you need to make any
change in version field in the desktop.version to trigger rebuild (this file is in the root of
your project) - this can be any change like just adding random char to the hashmeteor command unless you run it with --production - that is because development build
has devtron added and therefore the compatibilityVersion is differentPlugin is basically a module exported to a npm package. module.json is not needed and not taken
into account because name and dependencies are already in package.json. Also you can not use
the extract functionality as that only works in modules. Plugin settings are set and taken
from the plugins section of settings.json. Here is an example of passing settings to splash
screen plugin.
While developing you will probably need to make use of linkPackages in settings.json, so that
your npm-packaged plugin would be linked instead of downloaded. However the advised approach is
to make the development test driven - meaning that you should make your tests the main way of
verifying whether the plugin does what it should.
meteorDependencies in package.jsonOne extra feature is that you can also depend on Meteor packages through meteorDependencies
field in package.json. Check out meteor-desktop-localstorage for example.
A good practice when your plugin contains a meteor plugin is to publish both at the same version.
You can then use @version in the meteorDependecies to indicate that the Meteor plugin's
version should be equal to npm package version.
If you made a plugin, please let us know so that it can be listed here.
meteor-desktop-system-notifications
meteor-desktop-splashscreen
meteor-desktop-localstorage (deprecated, do not use from 1.0.0)
Squirrel Window and OSX autoupdates are supported. So far the only tested server is
electron-release-server and the
default url http://127.0.0.1/update/:platform/:version provided in settings.json assumes you
will be using it.
The :platform and :version tags are automatically replaced by correct values.
You can hook into Squirrel Windows events in squirrelEvents.js in .desktop.
More:
https://github.com/electron/electron/blob/master/docs/api/auto-updater.md
https://github.com/ArekSredzki/electron-release-server
This integration fully supports rebuilding native modules (npm packages with native node modules)
against Electron's node version. The mechanism is enabled by default.
Devtron is installed and activated by default. It is
automatically removed when building with --production. As the communication between your Meteor
app and the desktop side goes through IPC, this tool can be very handy because it can sniff on
IPC messages.
For unit tests you should not have problems with using electron-mocha.
For functional testing Spectron should be used.
There are two exemplary tests present in the default scaffold. Check them out as they have some
comments in them.
To run them you need to init functional test support by invoking:
npm run desktop -- init-tests-support
Two tasks should be added to your scripts section: test-desktop and test-desktop-watch.
Feel free to run the tests with: npm run test-desktop.
For testing modules there is a test suite available. It is used extensively in the plugins (splash screen & localstorage) tests so you can check there for more examples.
MD_LOG_LEVELMD_LOG_LEVEL env var is used to set the logger verbosity. It is set to
ALL by default but you can change it to any of INFO, WARN, ERROR, DEBUG, VERBOSE, TRACE. You can also
select multiple levels joining them with a comma, for example: INFO,WARN.
npm run desktop -- package <ddp-url>
This produces a package using electron-packager.
Package is produced and saved in .desktop-package directory. You can pass options via packagerOptions in
settings.json.
npm run desktop -- build-installer <ddp-url>
This packages and builds installer using electron-builder.
Installer is produced and saved in .desktop-installer directory. You can pass options via
builderOptions in settings.json.
If you do not pass any target platforms via --win, --linux or --mac it will build for your
current platform. If at least one the platform is specified, the current platform will not be
added automatically. So if you want to build Windows and Mac at the same time, being on Mac,
you need to pass --win --mac, not only --win. To check what targets you can build on certain platform and what does it require
check Multi-Platform-Build
Please note that electron-builder does not use electron-packager to create a package. So the
options from packagerOptions are not taken into account.
Currently there are some defaults provided only for Windows and Mac. If you want to build for
Linux you need to add a linux section in your builderOptions and comply to these
requirements.
Change target: ["appx"] in win section of builderOptions. In case of problems please refer to
electron-builder documentation.
This project recently hit 1.0.0 however you should still expect many breaking changes in the upcoming versions.
Any feedback/feature requests/PR is highly welcomed and highly anticipated.
If you want to check what is planned and what I am working on, first you can check accepted issues on github here. You can see the backlog and roadmap in form of epics on Taiga here. The project is public so you can also comment and vote there.
PRs are always welcome and encouraged. If you need help at any stage of preparing a PR, just file an issue. It is also good, to file a feature request issue before you start working to discuss the need and implementation approach.
If you want, you can always contribute by donating:
To help you contribute, there is a development environment setup script. If you have this repo
cloned and already did a npm install, you can just run it with node devEnvSetup.js.
However if you did not yet clone this repo just do:
mkdir tmp
cd tmp
wget https://raw.githubusercontent.com/wojtkowiak/meteor-desktop/master/devEnvSetup.js
npm install cross-spawn shelljs
node devEnvSetup.js
This script assumes you have npm, git and meteor available from the command line.
Currently this package does not work when linked with npm link. To set up your dev environment
it is best to create a clean Meteor project, add meteor-desktop to dependencies with a relative
path to the place where you have cloned this repo and in scripts add desktop with node ./path/to/meteor-desktop/dist/bin/cli.js.
Also to make changes in the desktop HCP plugins run Meteor project with METEOR_PACKAGE_DIRS
set to /absolute/path/to/meteor-desktop/plugins so that they will be taken from the cloned repo.
meteor-desktopBuilt an app using meteor-desktop? File an issue or PR to list it here.
How to disable
zipbuilding when usingbuild-installeron OSX.
Add target: ["dmg"] to mac section of builderOptions.
is here
v2.0.0 <sup>02.10.2018</sup>
The main aim of this version is to decouple electron, electron-builder and electron-packager from this package.
Until now every meteor-desktop release came with specific versions of those pinned to it.
Now you are free to use any version with your meteor project. Just add them to your devDependencies.
If you will not, meteor-desktop adds the recommended versions automatically when needed.
From now every meteor-desktop release will provide a recommended versions numbers of these dependencies.
By default I will try to make meteor-desktop compatible within the compatibility version of the recommended version i.e. if the recommended electron version is 2.0.10 you should still be able to use any 2.x.x version without problems.
Recommended versions:
electron -> 2.0.10electron-builder -> 20.28.4BREAKING:
support for Squirrel autoupdate mechanism ended, if you wish to continue with it, add the electron-builder-squirrel-windows dependency to your devDependencies and move it's settings to squirrel section in settings i.e.:
"squirrel": {
"autoUpdateFeedUrl": "http://127.0.0.1/update/:platform/:version",
"autoUpdateFeedHeaders": {},
"autoUpdateCheckOnStart": true
},
All builtin support will be definitely removed in January 2019.
FAQs
Build a Meteor's desktop client with hot code push.
The npm package meteor-desktop receives a total of 134 weekly downloads. As such, meteor-desktop popularity was classified as not popular.
We found that meteor-desktop demonstrated a not healthy version release cadence and project activity because the last version was released a year ago. It has 1 open source maintainer collaborating on the project.
Did you know?
Socket for GitHub automatically highlights issues in each pull request and monitors the health of all your open source dependencies. Discover the contents of your packages and block harmful activity before you install or update your dependencies.
Research
Security News
Socket’s threat research team has detected six malicious npm packages typosquatting popular libraries to insert SSH backdoors.
Security News
MITRE's 2024 CWE Top 25 highlights critical software vulnerabilities like XSS, SQL Injection, and CSRF, reflecting shifts due to a refined ranking methodology.
Security News
In this segment of the Risky Business podcast, Feross Aboukhadijeh and Patrick Gray discuss the challenges of tracking malware discovered in open source softare.