Table of Contents
Repositories
- keeweb
- the main repository containing the application code, desktop installers, and other support files
- app.keeweb.info
- kdbxweb
- core library used to read and write the KDBX file format
- keeweb-plugins
- plugin repository for KeeWeb
- contains plugins, themes, and translations
- plugins.keeweb.info
- keeweb-site
- our promotional website
- keeweb.info
- favicon-proxy
- CORS-enabled proxy used to load favicons from websites
- favicon.keeweb.info
- keeweb-tools
- tools for low-level working with kdbx files
- tools.keeweb.info
- keeweb-native-modules
- pre-built native modules used in KeeWeb
- ...forks of some repositories that can be found in keeweb organization
KeeWeb repository layout
Let's take a closer look at keeweb repository.
It consists of the following parts:
app
: application source code, both web and desktopbuild
: build system tasks and the webpack configdesktop
: source code of the desktop part, entry point of the Electron appgraphics
: icons and imagesimg
: screenshots for the README on GitHubpackage
: support files for packagers, docker images, and installersplugins
: infrastructure for developing plugins and plugin examplestest
: testsutil
: utility scripts for performing different tasks on the repositorygrunt*.js
: build system configuration files and task definitions
Application
Now let's dive deeper into the structure of the application code located in keeweb/app folder.
icons
: website faviconslib
: 3rd-party code that doesn't exist in npmmanifest
: manifests for different browsersbrowserconfig.xml
: Microsoft Edge favicons definitionmanifest.json
: SPA manifest for other browsers
resources
: resources embedded in the applicationDemo.kdbx
: demo databasepublic-key.pem
: public key used to verify plugin and update signaturespublic-key-new.pem
: rotated public key
scripts
: JS source code rootapp.js
: entry pointauto-type
: auto-type engine used in desktop appscollections
: collection models with their methods, such as list of open filescomp
: complex components with business logic using utilities, views, events, and so onconst
: constant definitionsframework
: micro-framework used in the app: models, collections, views, and eventshbs-helpers
: helpers for Handlebars used in templateslocales
: translations distributed with the appmodels
: models, such as file, entry, group, and so onplugins
: plugin enginepresenters
: presentation-layer model extensionsstorage
: implementation of storage, such as Dropbox, Google Drive, WebDAV, and othersutil
: utility classes, they are similar co components, but they don't have dependencies and business logicviews
: view controllers
styles
: SCSS styles rootmain.scss
: entry pointareas
: styles divided by parts of the app, such as footer or headerbase
: common styles, such as global font stackcommon
: SCSS components used on different areas of the applicationthemes
: theme definitionsutils
: SCSS utilities and mixins
templates
: Handlebars templates rootfavicon.png
: favicon for the websiteindex.html
: HTML page template where all scripts and styles are importedmanifest.appcache
: not used for caching anymore, contains only update information for desktop appsservice-worker.js
: service worker used for caching and update management
Frameworks
The app is built on our own micro-framework that is similar to Backbone. Originally it was on Backbone, but we were not using much of it and the number of limitations became more than problems solved. The current framework consists of these building blocks:
- events (the
EventEmitter
module from node.js) - model
- collection
- view
Views are built on Handlebars.js and rendered with morphdom, which gives us a possibility to re-render them without losing input state. New code should be written in reactive style, however there are some direct DOM modifications in different places, ideally they should be replaced.
SCSS styles are using Bourbon as a framework. We have our own theme engine that supports switching themes with CSS custom properties.
Desktop apps are created with Electron.
Building
The app is bundled with WebPack and built with Grunt. While it's so 2010s to use Grunt nowadays, it's still far ahead of using npm scripts and perfectly does the job of running different actions with JS. However it's not used for any of web bundle building tasks, this part is completely moved to WebPack.
Desktop apps are packaged with electron-packager and then built into distributables with Grunt. We're not using electron-builder for major installers (Windows MSI, macOS app, .deb, .zip) because the setup process is heavily customized and patching electron-builder would be way harder than implementing builders on our own. However electron-builder is used for various Linux packages, such as Snap or AppImage.
Native modules
KeeWeb uses native modules (node.js C++ addons) in desktop apps. All modules used in KeeWeb are built in keeweb-native-modules repository. Native modules are created:
- if the functionality is not available in Electron, for example, YubiKey API
- when implementing it in JavaScript would be significantly slower, for example, Argon2
In other cases it's better to implement everything in JavaScript. For example, a native module for reading QR codes would not be an acceptable solution.
List of used native modules:
node-keyboard-auto-type
: auto-type implemented usingkeyboard-auto-type
node-argon2
: faster Argon2 for desktop appsnode-keytar
: secret management, used for settings encryptionnode-yubikey-chalresp
: YubiKey interactionnode-usb-detection
: for watching USB devices and displaying the YubiKey iconnode-secure-enclave
: Touch ID support on macOS
Getting started
FAQ
Supported Platforms
iOS
Auto Type
Browser AutoFill
YubiKey
Contributing
About KeeWeb
Self-hosting and configuration
Configuration
WebDAV Config
Dropbox and GDrive
Developing and extending KeeWeb
The only official web app is https://app.keeweb.info