diff --git a/README.md b/README.md index 68c6e365..f836d823 100644 --- a/README.md +++ b/README.md @@ -15,9 +15,9 @@ ## What is this? -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 +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. ## Prerequisites @@ -34,13 +34,13 @@ push implementation - which means you can release updates the same way you are u 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` + # or in one command `npm run desktop -- --scaffold` ``` ## Usage `--help` @@ -84,15 +84,15 @@ Usage: npm run desktop -- [command] [options] this will also work with -b ``` #### `--build-meteor` -If 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 +If 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. - + #### `--android` -When 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 +When 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. - + Documentation ================= * [Architecture](#architecture) @@ -142,14 +142,14 @@ Documentation 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 +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 +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. @@ -159,24 +159,24 @@ Below is a high level architecture diagram of this integration. #### How does this work with Meteor? > or how hacky is this? -The main goal was to provide a non hacky integration without actually submitting any desktop +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. +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. -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 +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. #### How the `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 +- `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 `.asar` - `desktop.asar` - processed contents from `.desktop` @@ -187,17 +187,17 @@ While developing, the `app` is not asared so you can take a closer look at the ` #### Where is my `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 +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`. ## Scaffolding your desktop app -If you have not run the example from the Quick start paragraph, first you need to scaffold a +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` +To do that run: (assuming `npm install --save-dev meteor-desktop` did add successfully a `desktop` entry in the `package.json scripts` section) ```bash npm run desktop -- init @@ -225,7 +225,7 @@ Some files are described more in detail below.. ### settings.json This is the main configuration file for your desktop app. -Below you can find brief descriptions of the fields. +Below you can find brief descriptions of the fields. field|description -----|----------- @@ -260,21 +260,21 @@ field|description ##### Applying different window options for different OS -You can use `_windows`, `_osx`, `_linux` properties to set additional settings for different OS. +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. ##### Supported dependency version types -Only explicit versions are supported to avoid potential problems with different versions being +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. +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. ### desktop.js -The `desktop.js` is the entrypoint of your desktop app. Let's take a look what references we +The `desktop.js` is the entrypoint of your desktop app. Let's take a look what references we receive in the constructor. ```javascript /** @@ -299,8 +299,8 @@ This is a reference to the Skeleton App. Currently there are only two methods yo #### `eventsBus` -This 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 +This 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 @@ -310,16 +310,16 @@ event name|payload|description `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 +`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`](https://github.com/electron/electron/blob/master/docs/api/browser-window.md) 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`](https://github.com/electron/electron/blob/master/docs/api/browser-window.md) (`Chrome` window with `Meteor` app) is created, passes a reference to this window +`windowCreated`|`(window)`|emitted when the [`BrowserWindow`](https://github.com/electron/electron/blob/master/docs/api/browser-window.md) (`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) +`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 @@ -328,10 +328,10 @@ like for instance `myModule.initalized`. #### `modules` -Object with references to other modules and plugins. Plugins can be found under their names i.e., +Object 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 +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). #### `Module` @@ -340,23 +340,23 @@ Class that provides a way of defining API reachable by `Meteor` app - [more](#mo ## Writing modules -Module is just an encapsulated piece of code. Usually you would just provide certain type of +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 +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 +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` object - `dependencies` - list of npm deps -- `extract` - list of files that should be excluded from packing into `.asar` (e.g. executables, +- `extract` - 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 constructor +- `settings` - this object is passed as `settings` field in the object passed to module constructor #### `extract` -A 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 +A 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` @@ -373,13 +373,13 @@ export default class Desktop { ## Hot code push support -Applications produced by this integration are fully compatible with `Meteor`'s hot code push +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](https://guide.meteor.com/mobile.html#recovering-from-faulty-versions). You can configure the timeout via +The faulty version recovery is also in place - [more about it here](https://guide.meteor.com/mobile.html#recovering-from-faulty-versions). You can configure the timeout via `webAppStartupTimeout` field in `settings.json`. Versions are downloaded and served from [`userData`](https://github.com/electron/electron/blob/master/docs/api/app.md#appgetpathname) directory. -There you can find `autoupdate.json` and `versions` dir. If you want to return to first +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. @@ -390,26 +390,26 @@ In your `Meteor` app to run a part of the code only in the desktop context you c ## Accessing local filesystem in Meteor -Local filesystem is exposed under and url alias (similarly to [Cordova integration](https://guide.meteor.com/mobile.html#accessing-local-files)). -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 is exposed under and url alias (similarly to [Cordova integration](https://guide.meteor.com/mobile.html#accessing-local-files)). +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/` url. You can use some convenience methods: - **`Desktop.getFileUrl(absolutePath)`** - returns an url to a file -- **`Desktop.fetchFile(absolutePath)`** - invokes `fetch` on a file's url and returns it's -`Promise` +- **`Desktop.fetchFile(absolutePath)`** - invokes `fetch` on a file's url and returns it's +`Promise` ## Accessing `.desktop/assets` in Meteor Assets are exposed over an url alias `\___desktop\`. -So to display an image named `test.png` from `.desktop/assets` you should use a +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 url -- **`Desktop.fetchAsset(assetPath)`** - invokes `fetch` on an asset's url and returns it's -`Promise` +- **`Desktop.fetchAsset(assetPath)`** - invokes `fetch` on an asset's url and returns it's +`Promise` ## `Desktop` and `Module` - communication between Meteor and Electron @@ -445,12 +445,12 @@ There are two extra methods: Example of `send` and `fetch` usage - [here](https://github.com/wojtkowiak/meteor-desktop-localstorage/blob/master/plugins/localstorage/localstorage.js#L9). ## desktopHCP - `.desktop` hot code push -> #### experimental! +> #### experimental! 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 +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) +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. @@ -461,51 +461,51 @@ The `compatibilityVersion` is calculated from combined list of: - dependencies from all modules in `.desktop/modules` - major version of `meteor-desktop` (X.Y.Z - only X is taken) - major version from `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 + +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. - + #### How this works 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. -#### Caveats +#### Caveats - desktop app needs to be restarted when a new bundle is applied -- the bundled desktop app goes over normal HCP mechanism meaning that a `desktop.asar` file will -also be +- the bundled desktop app goes over normal HCP mechanism meaning that a `desktop.asar` file will +also be distributed to your mobile clients and cause unnecessary updates in case you only made changes in `.desktop` -- files that are excluded from `desktop.asar` (via `extract` settings in a desktop module) are +- files that are excluded from `desktop.asar` (via `extract` settings in a desktop module) are not updated, nor checked for changes! - if you had errors (i.e. syntax) in `.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 + 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 hash - if your run a production build of your desktop app it will not receive updates from project run - from `meteor` command unless you run it with `--production` - that is because development build + from `meteor` command unless you run it with `--production` - that is because development build has `devtron` added and therefore the `compatibilityVersion` is different - after reload logs will no longer be shown in the console ## How to write plugins Plugin 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](scaffold/settings.json#L26) is an example of passing settings to splash + 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](scaffold/settings.json#L26) 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 + + 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.json` -One extra feature is that you can also depend on Meteor packages through `meteorDependencies` +#### `meteorDependencies` in `package.json` +One extra feature is that you can also depend on Meteor packages through `meteorDependencies` field in `package.json`. Check out [`meteor-desktop-localstorage`](https://github.com/wojtkowiak/meteor-desktop-localstorage/blob/master/package.json#L52) 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 +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. @@ -516,9 +516,9 @@ If you made a plugin, please let us know so that it can be listed here. ## Squirrel autoupdate support (DEPRECATED) -Squirrel Window and OSX autoupdates are supported. So far the only tested server is -[`electron-release-server`](https://github.com/ArekSredzki/electron-release-server) and the -default url `http://127.0.0.1/update/:platform/:version` provided in `settings.json` assumes you +Squirrel Window and OSX autoupdates are supported. So far the only tested server is +[`electron-release-server`](https://github.com/ArekSredzki/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`. @@ -530,13 +530,13 @@ https://github.com/ArekSredzki/electron-release-server ## Native modules support This integration fully supports rebuilding native modules (npm packages with native node modules) - against `Electron's` `node` version. The mechanism is enabled by default. + against `Electron's` `node` version. The mechanism is enabled by default. ## Devtron -[`Devtron`](http://electron.atom.io/devtron/) is installed and activated by default. It is +[`Devtron`](http://electron.atom.io/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 + app and the desktop side goes through IPC, this tool can be very handy because it can sniff on IPC messages. ![devtron IPC sniff](docs/devtron_ipc.gif) @@ -545,7 +545,7 @@ automatically removed when building with `--production`. As the communication be For unit tests you should not have problems with using [electron-mocha](https://github.com/jprichardson/electron-mocha). For functional testing [Spectron](http://electron.atom.io/spectron) should be used. -There are two exemplary tests present in the default scaffold. Check them out as they have some +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: ``` @@ -555,12 +555,12 @@ Two tasks should be added to your `scripts` section: `test-desktop` and `test-de Feel free to run the tests with: `npm run test-desktop`. For testing modules there is a [test suite](https://github.com/wojtkowiak/meteor-desktop-test-suite) available. -It is used extensively in the plugins (splash screen & localstorage) tests so you can check there -for more examples. +It is used extensively in the plugins (splash screen & localstorage) tests so you can check there +for more examples. ## `MD_LOG_LEVEL` -`MD_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 +`MD_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`. ## Packaging @@ -568,7 +568,7 @@ select multiple levels joining them with a comma, for example: `INFO,WARN`. `npm run desktop -- package ` This produces a package using [`electron-packager`](https://github.com/electron-userland/electron-packager). -Package is produced and saved in `.desktop-package` directory. You can pass options via `packagerOptions` in +Package is produced and saved in `.desktop-package` directory. You can pass options via `packagerOptions` in `settings.json`. ## Building installer @@ -576,40 +576,40 @@ Package is produced and saved in `.desktop-package` directory. You can pass opti `npm run desktop -- build-installer ` This packages and builds installer using [`electron-builder`](https://github.com/electron-userland/electron-builder). -Installer is produced and saved in `.desktop-installer` directory. You can pass options via +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 +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](https://github.com/electron-userland/electron-builder/wiki/Multi-Platform-Build) - -Please note that `electron-builder` does not use `electron-packager` to create a package. So the + +Please note that `electron-builder` does not use `electron-packager` to create a package. So the options from `packagerOptions` are not taken into account. ##### Building for linux Currently there are some defaults provided only for `Windows` and `Mac`. If you want to build for - `Linux` you need to add a [`linux`](https://github.com/electron-userland/electron-builder/wiki/Options#LinuxBuildOptions) section in your `builderOptions` and comply to these - [requirements](https://github.com/electron-userland/electron-builder/wiki/Multi-Platform-Build#linux). + `Linux` you need to add a [`linux`](https://github.com/electron-userland/electron-builder/wiki/Options#LinuxBuildOptions) section in your `builderOptions` and comply to these + [requirements](https://github.com/electron-userland/electron-builder/wiki/Multi-Platform-Build#linux). ##### Building for Windows Store (AppX) -Change `target: ["appx"]` in `win` section of `builderOptions`. In case of problems please refer to +Change `target: ["appx"]` in `win` section of `builderOptions`. In case of problems please refer to [electron-builder](https://github.com/electron-userland/electron-builder) documentation. -## Roadmap +## Roadmap 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 +If you want to check what is planned and what I am working on, first you can check accepted issues on github [here](https://github.com/wojtkowiak/meteor-desktop/issues?q=is%3Aissue+is%3Aopen+label%3Aaccepted). -You can see the backlog and roadmap in form of epics on Taiga -[here](https://tree.taiga.io/project/wojtkowiak-meteor-desktop/kanban). The project is public so +You can see the backlog and roadmap in form of epics on Taiga +[here](https://tree.taiga.io/project/wojtkowiak-meteor-desktop/kanban). The project is public so you can also comment and vote there. ## Contribution -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 +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: @@ -617,25 +617,25 @@ If you want, you can always contribute by donating: Click here to lend your support to: meteor-desktop and make a donation at pledgie.com ! ##### ! devEnvSetup.js ! -To help you contribute, there is a development environment setup script. If you have this repo +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 +npm install cross-spawn shelljs npm 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 +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. - + 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. + ## Built with `meteor-desktop` Built an app using meteor-desktop? File an issue or PR to list it here. diff --git a/devEnvSetup.js b/devEnvSetup.js index 202d13a6..fcef4884 100644 --- a/devEnvSetup.js +++ b/devEnvSetup.js @@ -116,7 +116,7 @@ question('Do you want to use another path (yes/no)? ') }); } console.log('\nCreating meteor-desktop-test-app'); - exec('meteor create meteor-desktop-test-app --release=METEOR@1.4.2.7'); + exec('meteor create meteor-desktop-test-app --release=METEOR@1.6'); console.log('Installing deps in meteor-desktop...\n'); return spawn(npm, ['install'], path.join(resolvedPath, 'meteor-desktop')); diff --git a/lib/electronApp.js b/lib/electronApp.js index 191b5a63..692f4191 100644 --- a/lib/electronApp.js +++ b/lib/electronApp.js @@ -842,7 +842,7 @@ export default class ElectronApp { const uglifyingEnabled = 'uglify' in settings && !!settings.uglify; - const preset = presetEnv(undefined, { targets: { node: '8' } }); + const preset = presetEnv({ assertVersion: () => {} }, { targets: { node: '8' } }); const { data: files } = await this.$.utils.readDir(this.$.env.paths.desktopTmp.root); diff --git a/lib/electronBuilder.js b/lib/electronBuilder.js index c47ea38b..268be9d2 100644 --- a/lib/electronBuilder.js +++ b/lib/electronBuilder.js @@ -147,7 +147,7 @@ export default class InstallerBuilder { this.platforms = this.platforms .filter(platform => platform !== context.electronPlatformName); if (this.platforms.length !== 0) { - return Promise.resovle(); + return Promise.resolve(); } return new Promise((resolve, reject) => { shell.config.fatal = true; diff --git a/lib/meteorApp.js b/lib/meteorApp.js index a0986a02..c00bd16c 100644 --- a/lib/meteorApp.js +++ b/lib/meteorApp.js @@ -474,7 +474,6 @@ export default class MeteorApp { !~line.indexOf('--production') && !~line.indexOf('Output exceeds ') && !~line.indexOf('Node#moveTo') && - !~line.indexOf('Browserslist') && // ignore error releated to Browserslist ( Array.isArray(self.$.env.options.ignoreStderr) && self.$.env.options.ignoreStderr.every(str => !~line.indexOf(str)) diff --git a/package-lock.json b/package-lock.json index 563e7973..aa5aec51 100644 --- a/package-lock.json +++ b/package-lock.json @@ -1,6 +1,6 @@ { "name": "meteor-desktop", - "version": "2.0.0", + "version": "2.1.0", "lockfileVersion": 1, "requires": true, "dependencies": { @@ -6532,9 +6532,9 @@ } }, "lodash": { - "version": "4.17.14", - "resolved": "https://registry.npmjs.org/lodash/-/lodash-4.17.14.tgz", - "integrity": "sha512-mmKYbW3GLuJeX+iGP+Y7Gp1AiGHGbXHCOh/jZmrawMmsE7MS4znI3RL2FsjbqOyMayHInjOeykW7PEajUk1/xw==" + "version": "4.17.15", + "resolved": "https://registry.npmjs.org/lodash/-/lodash-4.17.15.tgz", + "integrity": "sha512-8xOcRHvCjnocdS5cpwXQXVzmmh5e5+saE2QGoeQmbKmRS6J3VQppPOIt0MnmE+4xlZoumy0GPG0D0MVIQbNA1A==" }, "lodash._basecopy": { "version": "3.0.1", diff --git a/package.json b/package.json index c97ee43d..3a67fec6 100644 --- a/package.json +++ b/package.json @@ -83,7 +83,7 @@ "del": "2.2.2", "install-local": "0.6.0", "isbinaryfile": "3.0.3", - "lodash": "4.17.14", + "lodash": "4.17.15", "md5": "2.2.1", "mksnapshot": "0.3.5", "node-fetch": "2.2.0",