I experienced an inability to build an app for electron until I installed unit tests. Could be related? Probably not, though.

I was just playing around with Quasar to see if I liked it and wanted to test the out-of-the-box support for Electron. I fired up a new app and immediately had errors:

$> npm install -g @quasar/cli
$> quasar create test-app
$> cd test-app
$> quasar build --mode electron --target win32

I made no changes to the starting code. After the long build process, I was met with this error:

 app:electron Bundling app with electron-packager... +3ms

(node:21956) UnhandledPromiseRejectionWarning:   TypeError: Cannot read property 'version' of undefined

  - index.js:119 Promise
    [test-app]/[@quasar]/app/lib/electron/index.js:119:56

  - new Promise

  - index.js:112 Promise.then.then
    [test-app]/[@quasar]/app/lib/electron/index.js:112:14

  - next_tick.js:68 process._tickCallback
    internal/process/next_tick.js:68:7


(node:21956) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). (rejection id: 2)
(node:21956) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.

I was able to accidentally resolve this error by installing Jest:

$> quasar ext add @quasar/testing
(select only Jest, and configure however you want)
$> quasar build --mode electron --target win32

I haven’t done exhaustive testing. Maybe you can install any testing framework and it fixes it. Maybe you can install any app extension and it fixes it (not just testing frameworks). Maybe running any non-build quasar command before running quasar build fixes it. Whatever the case, the error goes away after installing Jest.

This list reminds me of https://goodui.org/

Good UI used to tell you explicitly “pattern A out-performed pattern B”, but now they make you pay to see that. They just show two patterns side-by-side. Using intuition you can probably guess which ones are better, though.

Just an idle curiosity I had. It seems to me like the design goal of Quasar is to implement as many best practices and useful tools as possible (tree shaking, Vue, Material Design, date utilities, color utilities, etc) - and most apps would be incomplete without some central data persistence.

Clearly not every app needs to sync data with a central server (a personal budgeting app may be just as good storing its data locally), and clearly not all central persistence has to come in any standard form (you could open a raw TCP socket to send back binary-encoded data, you could rely on REST endpoints, or you could transfer whole SQLite files if you wanted to piss off and horrify every dev who ever lived). But there are a few standards that are widely adopted and used across the vast majority of modern apps. Specifically, most apps either use:

• RESTful API endpoints acting as a thin layer of an Entity-Relationship model managed by some back-end ORM (e.g. “GET /users”, “DELETE /users/3”, “POST /comment”)
• GraphQL

If Quasar provided helpers for interacting with these two (or just one of these two) common API types, it could reduce app development time drastically. Bonus points if such a helper were integrated with Vuex so you merely had to define your models and you magically had access to them all in your components.

I was just curious if such a thing existed or was in the works with Quasar. It seems like they’re trying to be a “one-stop shop” for cross-platform app development, and this would really seal the deal if it’s already a feature.