* add user asymmetric key api service
* Add user asymmetric key regen service
* add feature flag
* Add LoginSuccessHandlerService
* add loginSuccessHandlerService to BaseLoginViaWebAuthnComponent
* Only run loginSuccessHandlerService if webAuthn is used for vault decryption.
* Updates for TS strict
* bump SDK version
* swap to combineLatest
* Update abstractions
* [deps] Platform: Update electron to v33
* fix: remove event from minimize
* chore: update electron version in `electron-builder.json`
---------
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
Co-authored-by: Andreas Coroiu <andreas.coroiu@gmail.com>
Co-authored-by: Bernd Schoolmann <mail@quexten.com>
* Use typescript-strict-plugin to iteratively turn on strict
* Add strict testing to pipeline
Can be executed locally through either `npm run test:types` for full type checking including spec files, or `npx tsc-strict` for only tsconfig.json included files.
* turn on strict for scripts directory
* Use plugin for all tsconfigs in monorepo
vscode is capable of executing tsc with plugins, but uses the most relevant tsconfig to do so. If the plugin is not a part of that config, it is skipped and developers get no feedback of strict compile time issues. These updates remedy that at the cost of slightly more complex removal of the plugin when the time comes.
* remove plugin from configs that extend one that already has it
* Update workspace settings to honor strict plugin
* Apply strict-plugin to native message test runner
* Update vscode workspace to use root tsc version
* `./node_modules/.bin/update-strict-comments` 🤖
This is a one-time operation. All future files should adhere to strict type checking.
* Add fixme to `ts-strict-ignore` comments
* `update-strict-comments` 🤖
repeated for new merge files
Refactor the remaining logic from gulp. Part of the browser build script
refactor effort.
Webpack is now responsible for performing most of the operations previously
done by gulp. This includes: - Setting browser specific class - Building the
manifest file The `package.json` is modified to include browser specific
commands for `build`, `build:prod`, `build:watch` and `dist`.
# Manifests
Manifests now uses the `copy-webpack-plugin` `transform` feature. The logic is
located in `apps/browser/webpack/manifest.js`. It reads a template, which
supports some basic operations primarily overriding with browser specific
fields using `__browser__`. The `manifest.json` for both regular and mv3
builds are identical to our existing manifests except:
- `applications` renamed to `browser_specific_settings`.
- `permissions` sorted alphabetically.
# Safari build
Safari requires additional packaging commands. This is implemented as a
powershell script due to the cross-platform nature, and since we generally
require powershell in our distribution pipelines. An alternative would be to
write it in bash, but bash is less powerful and would require some additional
commands like `jq`. Another alternative is to write it using js, but that would
require additional dependencies.
Refactor the remaining logic from gulp. Part of the browser build script
refactor effort.
Webpack is now responsible for performing most of the operations previously
done by gulp. This includes: - Setting browser specific class - Building the
manifest file The `package.json` is modified to include browser specific
commands for `build`, `build:prod`, `build:watch` and `dist`.
# Manifests
Manifests now uses the `copy-webpack-plugin` `transform` feature. The logic is
located in `apps/browser/webpack/manifest.js`. It reads a template, which
supports some basic operations primarily overriding with browser specific
fields using `__browser__`. The `manifest.json` for both regular and mv3
builds are identical to our existing manifests except:
- `applications` renamed to `browser_specific_settings`.
- `permissions` sorted alphabetically.
# Safari build
Safari requires additional packaging commands. This is implemented as a
powershell script due to the cross-platform nature, and since we generally
require powershell in our distribution pipelines. An alternative would be to
write it in bash, but bash is less powerful and would require some additional
commands like `jq`. Another alternative is to write it using js, but that would
require additional dependencies.
