Post snapshot of the zap tool.

.babelrc

+{
+  "plugins": ["@babel/plugin-syntax-dynamic-import"],
+  "env": {
+    "test": {
+      "plugins": ["dynamic-import-node"],
+      "presets": [
+        [
+          "@babel/preset-env",
+          {
+            "modules": "commonjs",
+            "targets": {
+              "node": "current"
+            }
+          }
+        ]
+      ]
+    }
+  }
+}

.editorconfig

+root = true
+
+[*]
+charset = utf-8
+indent_style = space
+indent_size = 2
+end_of_line = lf
+insert_final_newline = true
+trim_trailing_whitespace = true

.eslintignore

+/dist

.eslintrc.js

+module.exports = {
+  root: true,
+
+  parserOptions: {
+    parser: 'babel-eslint',
+    sourceType: 'module'
+  },
+
+  env: {
+    browser: true
+  },
+
+  extends: [
+    // https://eslint.vuejs.org/rules/#priority-a-essential-error-prevention
+    // consider switching to `plugin:vue/strongly-recommended` or `plugin:vue/recommended` for stricter rules.
+    'plugin:vue/essential',
+    '@vue/standard'
+  ],
+
+  // required to lint *.vue files
+  plugins: [
+    'vue'
+  ],
+
+  globals: {
+    'ga': true, // Google Analytics
+    'cordova': true,
+    '__statics': true,
+    'process': true,
+    'Capacitor': true,
+    'chrome': true
+  },
+
+  // add your custom rules here
+  rules: {
+    // allow async-await
+    'generator-star-spacing': 'off',
+    // allow paren-less arrow functions
+    'arrow-parens': 'off',
+    'one-var': 'off',
+
+    'import/first': 'off',
+    'import/named': 'error',
+    'import/namespace': 'error',
+    'import/default': 'error',
+    'import/export': 'error',
+    'import/extensions': 'off',
+    'import/no-unresolved': 'off',
+    'import/no-extraneous-dependencies': 'off',
+    'prefer-promise-reject-errors': 'off',
+
+    // allow debugger during development only
+    'no-debugger': process.env.NODE_ENV === 'production' ? 'error' : 'off'
+  }
+}

.gitignore

+.DS_Store
+.thumbs.db
+node_modules
+
+generated-html
+
+# Temp generation file
+docs/zap-schema.dot
+
+# Quasar core related directories
+.quasar
+/dist
+
+#We don't save the coverage within 
+#this repo. 
+test/jest/coverage
+test/jest/__tests__/data/zap.sqlite
+
+# Cordova related directories and files
+/src-cordova/node_modules
+/src-cordova/platforms
+/src-cordova/plugins
+/src-cordova/www
+
+# Capacitor related directories and files
+/src-capacitor/www
+/src-capacitor/node_modules
+
+# BEX related directories and files
+/src-bex/www
+/src-bex/js/core
+
+# Log files
+npm-debug.log*
+yarn-debug.log*
+yarn-error.log*
+
+# Random test file that I keep using for the JSON output.
+test.json
+
+# Editor directories and files
+.idea
+.vscode
+*.suo
+*.ntvs*
+*.njsproj
+*.sln
+
+# Sonarqube stuff
+.scannerwork
+sonar-project.properties
+
+# Temporary place for handlebars stuff.
+src-electron/handlebars/out/

.gitmodules

+[submodule "zcl"]
+	path = zcl
+	url = ../zcl.git
+	branch = master

.postcssrc.js

+// https://github.com/michael-ciniawsky/postcss-load-config
+
+module.exports = {
+  plugins: [
+    // to edit target browsers: use "browserslist" field in package.json
+    require('autoprefixer')
+  ]
+}

.stylintrc

+{
+  "blocks": "never",
+  "brackets": "never",
+  "colons": "never",
+  "colors": "always",
+  "commaSpace": "always",
+  "commentSpace": "always",
+  "cssLiteral": "never",
+  "depthLimit": false,
+  "duplicates": true,
+  "efficient": "always",
+  "extendPref": false,
+  "globalDupe": true,
+  "indentPref": 2,
+  "leadingZero": "never",
+  "maxErrors": false,
+  "maxWarnings": false,
+  "mixed": false,
+  "namingConvention": false,
+  "namingConventionStrict": false,
+  "none": "never",
+  "noImportant": false,
+  "parenSpace": "never",
+  "placeholder": false,
+  "prefixVarsWithDollar": "always",
+  "quotePref": "single",
+  "semicolons": "never",
+  "sortOrder": false,
+  "stackedProperties": "never",
+  "trailingWhitespace": "never",
+  "universal": "never",
+  "valid": true,
+  "zeroUnits": "never",
+  "zIndexNormalize": false
+}

Jenkinsfile

+pipeline
+{
+    agent { label 'Zap-Build' }
+    
+    options { buildDiscarder(logRotator(artifactNumToKeepStr: '10')) }
+  
+    stages
+    {
+        stage('Git setup')
+        {
+            steps
+            {
+                script 
+                {
+                    checkout scm
+                    sh 'git submodule update --init --recursive'
+                }
+            }
+        }
+        stage('Npm install')
+        {
+            steps
+            {
+                script 
+                {
+                    sh 'npm install'
+                    sh 'npm list || true'
+                }
+            }
+        }
+        stage('License check')
+        {
+            steps
+            {
+                script 
+                {
+                    sh 'npm run lic'
+                }
+            }
+        }
+        stage('Build SPA layout for unit tests')
+        {
+            steps
+            {
+                script 
+                {
+                    sh 'npm run build-spa'
+                }
+            }
+        }
+        stage('Unit test execution')
+        {
+            steps
+            {
+                script 
+                {
+                    sh 'npm run test'
+                }
+            }
+        }
+        stage('Zap application build')
+        {
+            steps
+            {
+                script 
+                {
+                    sh 'npm run electron-build'
+                }
+            }
+        }
+	    stage('Generate HTML documentation')
+	    {
+            steps
+            {
+                script
+                {
+                    sh 'npm run doc'
+                }
+            }
+	    }
+        stage('Artifact creation')
+        {
+            steps
+            {
+                script 
+                {
+                    zip archive: true, dir: './dist/electron/zap-linux-x64', glob: '', zipFile: 'zap-linux-x64.zip'
+                    zip archive: true, dir: './dist/electron/zap-linux-ia32', glob: '', zipFile: 'zap-linux-ia32.zip'
+                    zip archive: true, dir: './dist/electron/zap-darwin-x64', glob: '', zipFile: 'zap-darwin-x64.zip'
+                    zip archive: true, dir: './dist/electron/zap-win32-ia32', glob: '', zipFile: 'zap-win32-ia32.zip'
+                    zip archive: true, dir: './dist/electron/zap-win32-x64', glob: '', zipFile: 'zap-win32-x64.zip'
+                    archiveArtifacts artifacts:'generated-html/**', fingerprint: true
+                }
+            }
+        }
+        stage('Build status resolution')
+        {
+            steps
+            {
+                script
+                {
+                    currentBuild.result = "SUCCESS"
+                }
+            }
+        }
+    }
+    post { 
+        always { 
+            script
+            {
+                def committers = emailextrecipients([[$class: 'CulpritsRecipientProvider'],
+                                                    [$class: 'DevelopersRecipientProvider']])
+
+                jobName = "${currentBuild.fullDisplayName}".replace("%2","/")
+                if(currentBuild.result != "SUCCESS")
+                {
+                    slackMessage=":zap_failure: FAILED: <${env.RUN_DISPLAY_URL}|"+jobName + ">, changes by: " + committers
+                    slackColor='#FF0000'
+                    slackSend (color: slackColor, channel: '#zap', message: slackMessage)
+                }
+                else
+                {
+                    slackMessage=":zap_success: SUCCESS: <${env.RUN_DISPLAY_URL}|"+jobName + ">, changes by: " + committers
+                    slackColor='good'
+                    slackSend (color: slackColor, channel: '#zap', message: slackMessage)
+                }
+            }
+            cleanWs()
+        }
+    }
+}

README.md

+![ZCL Advanced Platform](src-electron/icons/zap_128x128.png)
+
+# ZCL Advanced Platform
+
+## Quick instructions
+
+This is a node.js application. In order to run it, you need to have [npm](https://www.npmjs.com/) installed. Once you do, you can run:
+```
+npm install
+```
+which will download install all the project dependencies, and then run:
+```
+npm run zap
+```
+
+Refer to [more detailed instructions](docs/instructions.md) for more details.
+
+## Detailed Documentation
+
+* [Design](docs/design.md)
+* [Instructions](docs/instructions.md)
+* [API](docs/api.md)
+* [Release notes](docs/releasenotes.md)
+* [FAQ](docs/faq.md)
+

babel.config.js

+const fs = require('fs-extra')
+let extend = undefined
+
+/**
+ * The .babelrc file has been created to assist Jest for transpiling.
+ * You should keep your application's babel rules in this file.
+ */
+
+if (fs.existsSync('./.babelrc')) {
+  extend = './.babelrc'
+}
+
+module.exports = {
+  presets: [
+    '@quasar/babel-preset-app'
+  ],
+  extends: extend
+}

docs/design.md

+# Zigbee Advanced Platform (ZAP)
+
+The ZAP project delivers a ZCL configuration via an "advanced configurator" and a generator platform.
+
+- [Zigbe Advanced Platform](#zigbe-advanced-platform)
+  - [Use cases](#use-cases)
+    - [Standalone electron application](#standalone-electron-application)
+    - [Command line regeneration](#command-line-regeneration)
+    - [Integration with IDE](#integration-with-ide)
+  - [ZAP architecture](#zap-architecture)
+    - [Principles](#principles)
+    - [Architecture diagram](#architecture-diagram)
+  - [Front end](#front-end)
+  - [Generator and backend](#generator-and-backend)
+  - [Database schema](#database-schema)
+    - [Schema design principles](#schema-design-principles)
+    - [Schema diagram](#schema-diagram)
+  - [Embedded code](#embedded-code)
+  - [Versioning and backwards compatibility](#versioning-and-backwards-compatibility)
+    - [Compatibility considerations](#compatibility-considerations)
+    - [Dealing with the generation variant](#dealing-with-the-generation-variant)
+    - [Dealing with the XML files](#dealing-with-the-xml-files)
+  - [Dealing with multiple zap tool versions](#dealing-with-multiple-zap-tool-versions)
+  - [Documentation](#documentation)
+  - [Testing](#testing)
+  
+## Use cases
+
+This chapter lists the use cases that were envisioned for the ZAP 
+platform.
+
+### Standalone electron application
+
+In this scenario, the zap application is used standalone. It provides a `zap` executable, which, when launched without any argument shows the full UI, which allows the user to work with an application configuration, load/save configuration files and perform a generation out of the given configuration.
+
+### Command line regeneration
+
+The command-line case features the same `zap` executable, however it will support command line options, such as `zap -generate <input>` which will cause the application to run in a headless mode, and generate all the data out of the configuration without showing the UI.
+This will make the application well suited for integration into continuous integration tools, such as a build system like Jenkins.
+
+The zap tool is specifically design to support such a use case, as history shows that integration into CI process is critical for adoption of the tools into a wider ecosystem.
+
+### Integration with IDE
+
+A third use case is an integration into IDE. There are 2 integrations currently envisioned:
+* Integration with [VSCode](https://code.visualstudio.com/).
+* Integration with [Silicon Labs Simplicity Studio](https://www.silabs.com/products/development-tools/software/simplicity-studio).
+
+The integration with IDE has 2 parts:
+1. Visual integration, which enables using the UI directly inside a given IDE:
+   - VSCode naturally assimilates the web technology, since it is itelf written using electron. So the UI will fit naturally into its extensions model.
+   - Simplicity Studio provides jxbrowser for the integration, so it will use a jxbrowser based eclipse editor to show the UI.
+2. Generation integration, which enables automatic regeneration of the generated files when the configuration data changes.
+   - VSCode will provide an JS-based extension, that will be able to trigger the generation code. There is no plan to move generation code in-process with the VSCode, it will be used as an independent program to execute with the correct arguments.
+   - Simplicity Studio adapter pack technology will provide integration with the zap program for the generation.
+
+## ZAP architecture
+
+### Principles
+
+The ZAP architecture follows the standard guidelines for modern application development using node.js for backend and web technologies for frontend.
+The state of the application is stored in the back-end SQL database (initialy a [SQLite](https://www.sqlite.org/index.html) file on a desktop PC).
+
+All the frontend is developed using the [quasar framework](https://quasar.dev/), which is one of the primer front-end frameworks developed on top of the [Vue.JS platform](https://vuejs.org/). 
+
+Between the front-end and the back-end is the REST API, which allows for an reasonable separation between the two.
+
+The architectural design allows for the front-end user interface to be executed in any browser. The browser can be:
+* [standalone chrome browser](https://www.google.com/chrome/), pointing to a specific URL
+* [electron](https://www.electronjs.org/) renderer process, containing a chromium engine
+* other browser environment, such as [jxbrowser](https://www.teamdev.com/jxbrowser), which is a java-based wrapper around chromium engine, used by some IDEs to embed web-based UIs into its native environment.
+* any other browser environment that supports modern JS and is generally compatible with current standards
+
+### Architecture diagram
+
+![Architecture diagram](zap-architecture.png)
+
+## Front end
+
+Front-end of the "Zap" platform centers around the UI that replaces the current ZCL tab inside SimplicityStudio's AppBuilder. The following are the architectural guidelines:
+
+* The UI is written using standard HTML5 technologies, using Vue.JS and Quasar as an agreed-on UI framework.
+* The UI backing data are the ZCL XML files for static meta-data (shipped by SDK) and the customer-owned "zcl.config" file where customer data is saved (JSON)
+* The UI must not be tied to either electron or jxbrowser APIs, and should be usable in a plain chrome browser environment, to ensure portability at the JS level, 
+* The UI uses a common API that ties it to jxbrowser/electron/plain-browser environments via separate JS API layers for each environment, as described in "UI technologies for Wireless Tools"
+* The front-end can exist as external resources, as far as Studio is considered. It is based on loading a single toplevel HTML file (or external URL) and resolving relative URLs thereon, therefore the jxbrowser environment should be able to load it from the SDK if required, with minimal bridging access mechanism for file access.
+* The development environment for the the UI does not require the eclipse IDE, you can natively develop this using any standard webtech IDEs, such as vscode, atom, etc., so the entry point is much more light weight. This is very important, since in case of inexperienced developers, such environment has a much lower learning curve and allows for a much quicker contribution for resources well versed with webtech, but not with the eclipse/SWT development environment.
+* The initial custom-facing release requires that the Zap UI runs inside jxbrowser, as an eclipse editor inside full-blown legacy Simplicity Studio environment
+* additionally, the same UI will also be available for developers for use from command line via a simple "zclconfig <file>" command line execution, which will launch a simple electron-based app showing the exact same UI. User will be able to edit file, save changes and then proceed via command-line UC/UP generation/build process as defined by the UC/UP project.
+
+## Generator and backend
+
+The Zap back-end is a node.js application. The general design guidelines for the back-end logic are:
+
+* fully embrace and make use of the asynchronous node.js callback model, thus ensuring least-blocking and maximum-performing infrastructure.
+* use npm as a package manager.
+* During the development process, decide on the packaging model and how we distribute node runtime to the final environment.
+* Provide unit testing infrastructure, and a CI build that reacts on the code modifications automatically.
+
+Generator is closely tied to the changes in the embedded layers, but here we list mostly integration requirements:
+
+* Input to generator are:
+  * ZCL XML files 
+  * generation template files
+  * custom owned zcl.config file.
+  * custom generation template files
+
+* Output from generator are generated .c/.h files that the embedded code requires and a series of "generation instructions" that are the contributions to the Universal Configurator / Unified Platforom (UC/UP) project model (such as: headers defined, additional C/H files included, etc, etc.).
+
+* Generator will be packaged as a Simplicity Studio adapter pack, which ensures that it can be executed both from command-line without any studio present, as well as from full-blown Studio or whatever subset of Studio UC command-line ends up being.
+
+* A format of the output "generation instructions" yaml file (as described here: Advanced Configurator Generation Layer integration) will have to be agreed on with the Studio team.
+
+* For faster generation, in environments where an intermediate yaml file is NOT required, as both driver and driven processes are within the same process in memory, the generator could use a provided interface to populate generation instructions, instead of an intermediate yaml file.
+
+* Generator is not tied to the front-end in any way. We could, as a convenience, add a "preview mode" in the front-end UI, just to see what will generate, but the intent is to keep these decoupled and editing of the zcl.config file in a an editor is a separate process from generating content.
+
+## Database schema
+
+Back-end middle-layer is kept stateless, and all the data is kept in a relational database. 
+
+### Schema design principles 
+
+Following are the rules for the database schema:
+* Columns with the `_ID` postfix, are the primary key columns and should be declared as such in the schema.
+* Columns with the `_REF` postfix, are the foreign key columns, and should be constrained as such in the schema.
+* We should support `cascade delete` mechanism for tables with foreign keys.
+* All the primary keys are considered NON PERMANENT. What this means, is that between two runs of the application, there is no guarantee that these rows will survive, since the application always needs ability to start from a state where there is no database, and it will create one on the fly. This rule implies, that any exports (such as the configuration file saved to a local filesystem) *MUST NOT* contain any references to the specific primary key values.
+
+### Schema diagram
+
+Following picture shows the schema diagram. Note that the root information for the schema itself, is the [SQL script that creates the schema](src-electron/db/zap-schema.sql).
+
+![SQL schema diagram](zap-schema.svg)
+
+_Developer note_: If there are any changes to the SQL script, the picture should be regenerated via the `docs/make-schema-diagram` script.
+
+## Embedded code
+
+Following is the laundry-list of changes in the embedded code:
+
+* Rethink and reengineer entire ZCL embedded layers as a "addon library", that interfaces with lower layers via a well-defined API, instead of direct calls into the stack APIs wherever needed.
+
+* Develop the API for the Zigbee stack.
+
+* Develop the same API for the pure-simulation environment, which allows ZCL library to run in Posix environment, possibly on top of java simulator.
+
+* Abandon current mechanism of parsing OTA content and issuing callbacks for it, and replace it with a struct-driven event-bus approach.
+
+* Threads? (Discuss. TBD.)
+
+* Develop a clean API that allows from-the-top extensions, which are essentially customer callbacks to the ZCL command/attribute logic and ability to contribute custom commands and attributes from the top. (Either based on source-code approach or library add-ons.)
+
+* Rework the attribute storage logic: develop a reusable embedded database which covers all the features ZCL offering needs, while being an independent UP component, that can be used by any other part of the SDK as well. For example, BLE characteristics could use same database.
+
+## Versioning and backwards compatibility
+
+Zap infrastructure needs to be able to deal with the use case, where a user has multiple ZCL data packs installed and at the same time, the user may have multiple projects (either in IDE, or outside of it) opened simultaneously against one or more ZCL data packs.
+
+The tool rules that deal with multiple ZCL data pack versions are as follows...
+
+### Compatibility considerations
+
+Zap tools follows the following strict rules of backwards compatibility:
+
+- Each version of the tool, can read the `zcl.config` files created by itself, or by any older version of zap tool. 
+- It might not be able to read `zcl.config` file saved by future versions of the zap tool.
+- Each version of the tool, writes out only its own versions of the zcl.config files. This means that any time you read in a config file, and save it back out, it means it gets upgraded to the latest format.
+- Each version of the tool, can generate artifacts for its own version, or any older version of the SDK. The information about which generation variant is required, is saved in the zcl.config file.
+
+Consequences of these rules:
+
+- Once you have an upgraded version of the zap tool in your desktop environment, you should never downgrade.
+- If you have mutiple versions of the zap tool in your desktop environment, you should always execute the latest, and can safely delete all earlier versions.
+
+### Dealing with the generation variant
+
+Zap tool supports multiple variants of generation. Different versions of the SDK might require different variant. Variants are identified by an increasing integer number, starting with zero.
+
+- A desired variant of generation is recorded in the zcl.config file.
+Generation logic inside Zap tool is separated per-variant, so that each variant generator is isolated in a separate javascript module.
+- An initial variant is populated from the initial template of zcl.config file, that is copied into your project from the selection of the zcl component. 
+- Technically, users can always change the variant inside zcl.config file. But the user interface should not allow them to do that easily, since changing a variant makes no sense within a same ZCL data pack.
+- Upgrading the zcl.config file from one SDK to another, where a generation variant has increased, will result in the variant inside zcl.config file being upgraded.
+- As each version of zap tool, supports current and all older variants, you can always generate older variant projects from latest version of the tool.
+
+### Dealing with the XML files
+
+Zap tool needs to be able to read in and parse the XML files from all installed locations on demand, and hash them internally per SDK.
+
+When zap tool is asked to serve UI, or generate, it will require information which set of XML files to use. This information can be provided via a parameter to the tool. The driving entity (IDE?) will be able to pass that information to the zap program. Zap tool itself, will not be aware of a concept of SDK, beyond just keeping track of different directories where the XML files are present, so it can load them in as needed.
+
+## Dealing with multiple zap tool versions
+
+Following rules apply:
+
+- There is ALWAYS only one copy of the zap tool running. There is never a valid reason, nor should be allowed, to execute two versions of the zap tool in any normal flow. Zap tool will create a taskbar icon which will be an interface for the user to interact with the tool globally, without the context of the specific zcl.config file.
+- If the currently running version of the zap tool encounters a generation variant that is higher than the one it supports, or zcl.config file in a format higher than is supports it shows an error and prompts to upgrade the tool.
+- When a zap tool opens a zcl.config file, it will create a "session" for this zcl.config file. In case of UI, there will be a cookie on a browser side identifying the session. This way, you can open multiple browser windows against the same zap tool back-end to edit multiple files.
+Each "session" will know the following information:
+  - the user data that it is processing (the in-memory or in-database equivalent of the zcl.config file).
+  - the static SDK data (ZCL XML files) that match this user data, which is provided from the cache of all loaded XML files as described in the previous chapter.
+  - Sessions may be persisted and/or removed from in-memory representation due to inactivity. Final specific implementation TBD.
+
+Zap tool will be versioned with 2 tokens of information. These versions will be seen via a --version command line argument and they will be saved into the zcl.config file. The two tokens are:
+- The git commit # of the built version of tool.
+- A date of this git commit in a human readable form.
+
+There is no plans to give a zap tool any other version, such as "1.0.0" or "2.4.5" or something like that, since those would essentially just serve as obfuscated aliases to retrieve the two tokens mentioned before. If someone desires to build an 3-digit compliant version of the zap tool version (for example, in case where it needs to be packaged as an eclipse plugin or something, should we decide to distribute it that way), then the 3-digit version would be YEAR.MONTH.DAY of the git commit date.
+
+This might change in the future if there is a need for a clear marketing
+version of the product.
+
+## Documentation
+
+There are following aspects to the documentation of this project.
+
+The markdown formatted documents are commited in the repo, since the markdown format is easy to read in github. Following are the markdown formatted pieces of documentation:
+* hand-written markdown documents (such as this design document you're reading now)
+* generated Javascript API documentation from jsdoc comments in the code.
+* generated REST API documentation from jsdoc comments in the code.
+
+Besides the markdown, there is also a process to generate HTML documentation out of jsdoc and md files. The HTML documentation is not intended to be commited to git, but should be generated on the fly by the zap CI process.
+
+## Testing
+
+Unit testing was an extremely important for ZCL embedded apps, therefore the scope of existing unit tests needs to be maintained. Exact design TBD.
+

docs/faq.md

+# Frequently Asked Questions
+
+**Q: I get an error "sqlite3_node" not found or something like that.**
+
+**A:** The root reason for this is a missmatch of some of these things:
+  * your local global electron install
+  * your project-wide electron install
+  * your sqlite3 precompiled binding file
+  * some of the other node modules versions
+
+To fix this, run some combination of following commands (assuming electron version 8.0.1):
+  * `npm install`
+  * `npm install electron@8.0.1`
+  * `npm install electron@8.0.1 -g`
+  * `npm install node-abi@latest`
+  * `./node_modules/.bin/electron-rebuild -w sqlite3 -p`
+
+##
+

docs/instructions.md

+# Instructions
+
+This section lists instructions for various things you might need to do in this repo.
+
+**Install the dependencies:**
+
+```bash
+npm install
+```
+
+**Start the application:**
+
+```bash
+npm run zap
+```
+
+**Start the front-end in development mode:**
+
+(Supports hot-code reloading, error reporting, etc.)
+```bash
+quasar dev -m electron
+```
+or
+```
+npm run electron-dev
+```
+
+**Lint the files:**
+
+```bash
+npm run lint
+```
+
+**Build the app for production:**
+
+```bash
+quasar build -m electron
+```
+or
+```
+npm run electron-build
+```
+
+**Run the unit tests:**
+
+```bash
+npm run test
+```
+
+**Regenerate the API documentation:**
+
+```bash
+npm run apidoc
+```
+
+**Customize the configuration:**
+
+See [Configuring quasar.conf.js](https://quasar.dev/quasar-cli/quasar-conf-js).
+

docs/make-schema-diagram

+#!/bin/bash
+#
+# This script is generating a zap schema diagram out of a sqlite file.
+#
+# It assumes that you have installed a schemacrawler tool and few other things.
+# You can find schemacrawler at: https://www.schemacrawler.com/
+#
+# You need to have graphviz package installed for this to work correctly.
+
+# It also has only ever been tested on Linux.
+#
+
+SC_HOME=~/schemacrawler-16.4.1-distribution/
+SC_BIN=${SC_HOME}/_schemacrawler/schemacrawler.sh
+
+SQLITE=~/.silabs/zap/zap.sqlite
+SVG=zap-schema.svg
+
+echo "Creating schema diagram to ${SVG} from database at ${SQLITE} ..."
+
+
+# Generate the dot file using the schemacrawler
+${SC_BIN} --server sqlite --database=${SQLITE} --command=schema --info-level=standard --output-format=scdot --output-file=zap-schema.dot
+
+if [ ! $? -eq 0 ]; then
+  echo ""
+  echo "Error executing schemacrawler from ${SC_BIN}"
+  echo "Please make sure schemacrawler is properly installed."
+  echo ""
+  echo "You can download it from: https://www.schemacrawler.com/"
+  exit
+fi
+
+# Fix the background of all HTML tables to white
+sed -i 's/color="#888888"/color="#888888" bgcolor="#ffffff"/g' zap-schema.dot
+
+# Fix the overall background of the image to transparent
+sed -i 's/rankdir="RL"/rankdir="RL"\n    bgcolor="transparent"/g' zap-schema.dot
+
+# Make edges black and bold
+sed -i 's/edge \[/edge\[\n    color="black"\n    style="bold"/g' zap-schema.dot
+
+# Remove the date stamp, so we don't create unnecessary commits
+sed -i '/.*td align=.left..202.*/d' zap-schema.dot
+sed -i 's/>generated on/ colspan=\"2\">SQL schema is copyrighted by Silicon Labs./g' zap-schema.dot
+
+# Convert the dot to svg using the "dot" tool from graphviz
+dot -Tsvg zap-schema.dot -o ${SVG}
+if [ ! $? -eq 0 ]; then
+  echo ""
+  echo "Error executing 'dot' command from graphviz package."
+  echo "Please make sure graphviz is installed and on your PATH."
+  exit
+fi
+
+echo "Diagram created: ${SVG}"

docs/releasenotes.md

+# Release notes
+
+## Pre-release
+
+Nothing has been released yet.
\ No newline at end of file

jest.config.js

+module.exports = {
+  globals: {
+    __DEV__: true
+  },
+  globalSetup: '<rootDir>/test/global-setup.js',
+  globalTeardown: '<rootDir>/test/global-teardown.js',
+  setupFilesAfterEnv: [
+    '<rootDir>/test/jest/jest.setup.js'
+  ],
+  // noStackTrace: true,
+  // bail: true,
+  // cache: false,
+  // verbose: true,
+  // watch: true,
+  collectCoverage: true,
+  coverageDirectory: '<rootDir>/test/jest/coverage',
+  collectCoverageFrom: [
+    '<rootDir>/src/**/*.vue',
+    '<rootDir>/src/**/*.js',
+    '<rootDir>/src/**/*.jsx'
+  ],
+  coverageThreshold: {
+    global: {
+    //  branches: 50,
+    //  functions: 50,
+    //  lines: 50,
+    //  statements: 50
+    }
+  },
+  testMatch: [
+    '<rootDir>/test/*.test.js'
+  ],
+  moduleFileExtensions: [
+    'vue',
+    'js',
+    'jsx',
+    'json',
+    'ts',
+    'tsx'
+  ],
+  moduleNameMapper: {
+    '^vue$': '<rootDir>/node_modules/vue/dist/vue.common.js',
+    '^test-utils$': '<rootDir>/node_modules/@vue/test-utils/dist/vue-test-utils.js',
+    '^quasar$': '<rootDir>/node_modules/quasar/dist/quasar.common.js',
+    '^~/(.*)$': '<rootDir>/$1',
+    '^src/(.*)$': '<rootDir>/src/$1',
+    '.*css$': '<rootDir>/test/jest/utils/stub.css',
+    '.*\\.sql$': '<rootDir>/test/jest/__mocks__/zap-sql-mock.js',
+    "\\.(jpg|jpeg|png|gif|eot|otf|webp|svg|ttf|woff|woff2|mp4|webm|wav|mp3|m4a|aac|oga)$": "<rootDir>/test/jest/__mocks__/file-mock.js",
+  },
+  transform: {
+    '.*\\.vue$': 'vue-jest',
+    '.*\\.js$': 'babel-jest',
+    '.+\\.(css|styl|less|sass|scss|svg|png|jpg|ttf|woff|woff2)$': 'jest-transform-stub',
+    // use these if NPM is being flaky
+    // '.*\\.vue$': '<rootDir>/node_modules/@quasar/quasar-app-extension-testing-unit-jest/node_modules/vue-jest',
+    // '.*\\.js$': '<rootDir>/node_modules/@quasar/quasar-app-extension-testing-unit-jest/node_modules/babel-jest'
+  },
+  transformIgnorePatterns: [
+    '<rootDir>/node_modules/(?!quasar/lang)'
+  ],
+  snapshotSerializers: [
+    '<rootDir>/node_modules/jest-serializer-vue'
+  ]
+}