@frankieone/one-sdk 0.6.5-rc → 0.6.6-rc.7

package/README.md

@@ -1,483 +1 @@
-# Frankieone OneSDK
-
-This is the Typescript codebase for OneSDK
-
-## System requirements
-
-This list is incomplete.
-
-- NodeJS 17.1, to allow NODE json imports in a few of the build modules (Dode's --experimental-json-modules flag and import asserts)
-- NPM 8.1
-
-## Project structure
-
-This is not a monorepo. This codebase is split in directories, but has no concept of npm workspaces, or any sort of monorepo utilities to use
-
-- `modules`, where the codebase for the OneSDK is decoupled in "modules".
-  - **The entry file for the OneSDK build is the module `modules/index.ts`**
-- `apps`, where subdirectories contain the codebase for applications related to OneSDK. These Apps are mailny used for testing and validating the OneSDK in different environments and build systems. These are the application packages.
-  - `playground` A React application used for executing the local OneSDK source code, used for the development of the OneSDK.
-    Given this project imports the OneSDK modules directly, it uses the `modules` folder as a [TypeScript reference](https://www.typescriptlang.org/docs/handbook/project-references.html). Read more in "OneSDK Playground".
-  - `raw-js` A very basic Javascript project which uses the CDN release of the OneSDK, executed as a `UMD` module and injected in the browser as `window.oneSdk`.
-  - `raw-ts` A very basic TypeScript project which uses the NPM release of the OneSDK.
-  - `npm-import` An attempt to reproduce a non standard build system using Rollup. This is experimental and aims to reproduce Westpacs build system used with the OneSDK.
-- `tests` Where jest tests go. Try to keep the file structure as similar to the `modules` directory as possible.
-
-## Modules
-
-OneSDK modules are a way to easily increase the OneSDK functionalities. They are defined as objects exposing an `initialise` method that returns a `context` object.
-Once the module is initialised, the returned context object offers access to the internal state and functionalities of that instance of the module.
-
-Module definition:
-
-```
-export interface Module<
-  Params extends BaseModuleOptions = BaseModuleOptions,
-  Context extends ModuleContext = Omit<EventHub, "emit">
-> {
-  initialise(p: Params): Context;
-}
-```
-
-BaseModuleOptions is the set of options that all modules will receive, besides any specific options defined by the module itself:
-
-```
-export type BaseModuleOptions<InstanceName extends string = string> = SharedState & { instanceName: InstanceName };
-
-export type SharedState = {
-  globalEventHub: EventHub<GlobalEvents>;
-  frankieClient: FrankieApiClient;
-  oneSdkInstance: OneSDKContext;
-  recipe: RecipeParsed;
-  session: SessionMeta;
-} & Required<Omit<OneSDKRootParameters, "session">>;
-```
-
-A Module Context always exposes at minimum the event hub methods "on" and "off":
-
-```
-export type ModuleContext<
-  Context extends object = Record<string, unknown>,
-  Events extends EventsDictionary = Record<string, unknown[]>
-> = Context & Omit<EventHub<Events>, "emit">;
-```
-
-### Components
-
-The OneSDK exposes a method called `component(moduleName, options)`, which will 1) retrieve the module from the dictionary of modules present in `@common/constants`, 2) initialise/instantiate it with the provided options and 3) store the context object and the instance name in a dictionary of instances. The instance name is provided as the parameter `options.instanceName` and defaults to the parameter `moduleName`.
-
-> A component is the combination of an instantiated module's context object and the instance name assigned to it. Check the file `@module/sdk/types/components.ts`.
-
-### Instances
-
-Only one instance is created per each combination of `moduleName` and `options.instanceName`. Multiple calls to the `component` method with the same two values will always return the same instance, which keeps its state alive internally.
-
-### Lazy loading
-
-Components are supposed to lighten the OneSDK loading time by loading any necessary extra code asynchronously. Although the interface of a component isn't asynchronous, as its context object is provided immediately to the developer, the bulk of its source code is loaded as soon as the module identifies which vendor code it's supposed to load. In most cases it will then load a wrapper for that vendor containing any vendor source code or logic associated with initialising the integration with their service.
-
-- A `module` directory is expected to have the following structure
-
-  - `index.ts` exposing the modules interface.
-    This file will export an object called `{itsName}Module` with the method `initialise(BaseModuleOptions & LocalModuleOptions): ModuleContext`. Check the interface `Module` in `sdk/types/components.ts`
-  - `constants.ts`
-  - `parseConfiguration.ts` where options passed to the module are validated, which could lead to a hard failure (thrown exception).
-
-    <b style="color:red">TODO</b>: What does a hard failure look like for asynchronous code that isn't triggered by the developer?
-
-  - `vendors` directory for vendor specific wrappers
-  - `types` directory for module specific types
-    - `index.ts` barrel exports file, which reexports all types from a single module. It is just a helpful abstraction to the codebase
-    - `module.ts` types used by module's interfaces. Here will be declared the input options and the context object
-    - `wrapper.ts` types used to abstract different vendor wrappers. Here will be declared the common wrapper options and context object
-    - `events.ts` events exposed by this module's event hub
-
-_Caching strategies for asynchronous modules may be documented, where we give developers module specific urls, so they can signal to the browsers they might use some modules and the browser will download them in the background as soon as possible, without disturbing any other requests._ <b style="color:red">TODO</b>
-
-Description on how to create new modules here. <b style="color:red">TODO</b>
-
-Some OneSDK modules will be initialised automatically during the OneSDK initialisation and exposed via methods on the OneSDK instance directly. Besides their invocation, they are no different to modules invoked as "components".
-
-The Modules directory can also contain utilities, such as the `FrankieApiClient`, which abstracts integration to BFF and the more general `common` directory, where common types and small utilities are provided.
-
-### Frankie Api Client
-
-This BFF client is split in modules that cover different use cases. Some of them are
-
-1. "Applicant", for CRUD operations on entities of type "individual", which includes list of documents
-2. "Documents", mainly for Id Scan upload.
-3. "OCR", for running OCR in scans
-4. "IDV", for initialising sessions with vendors and running liveness and facial similarity checks
-
-Not all OneSDK modules need all those clients and for that reason, they may be invoked asynchronously as well. There are two ways to fetch an API Client module:
-
-1. Synchronously (which will bundle the source code with the current source code)
-
-   ```
-    import { FrankieApiClient, ApplicantClient } from "@module/frankie-client";
-    const bffClient = new FrankieApiClient("/baseurl");
-    const applicantsClient = new ApplicantClient(bffClient, { entityId: "some-id" });
-   ```
-
-2. Asynchronously, which will fetch this client only when needed
-
-   ```
-   const bffClient = new FrankieApiClient("/baseurl");
-   const applicantsClient = await bffClient.getClient("applicants", { entityId: "some-id" });
-   ```
-
-Description on how to create new clients here. <b style="color:red">TODO</b>
-
-## Reactivity
-
-In javascript, a plain object storing variables is not what you would call "reactive". Reactivity is implemented in different ways by different frameworks, but the most popular way to implement reactivity is using a library called RXJS, which is backed by big names such as Microsoft.
-RXJS (Reactive Extension for Javascript) allows us to build declarative, data driven applications, instead of fully procedural. [Read about it here](https://x-team.com/blog/rxjs-observables/).
-
-Due to its popularity, RXJS is native to Angular, easily supported by Vue with an official plugin and easily adopted by React with custom hooks. Since it's built in plain Javascript, any framework can find ways to integrate with it.
-
-In OneSDK we will use it to implement internal reactive state, which is used to propagate change as data streams, instead of static values. The entire application will then be aligned with a single source of truth, instead of manual updates that would be required if using events. At the same time, simple use cases require imperative options which, due to the lack of conceptual challenges, are much easier to understand. We aim to offer both alternatives: A reactive and an imperative.
-
-The class `ReactiveStore` extends RXJS observables to offer a developer friendly way to read and right from the internal state.
-
-`ReactiveStore::constructor(StateDictionary)`
-
-```
-const internalState$ = new ReactiveStore({
-  dataFieldA: "initialValue",
-  dataFieldB: { a: 1, b: 2, c: 3 },
-  dataFieldC: new Clonable()
-})
-```
-
-To enforce **immutability**, and hence avoiding weird reference bugs that are extremely hard to debug, all data passed to reactive store becomes immutable. Whenever reading a value from it, **you'll always receive a copy of the original value**. For that reason, **all class instances** passed to the data, at any level **need to implement the interface** `Clonable<T> { clone(): T }`. Any other JS native values (dictionaries, arrays and primitives) will be recursively resolved. Check the file `objectUtils.ts` for details.
-
-To read from the object `internalState$` defined above we need to destructure its individual fields with the method
-
-```
-ReactiveStore::getRootAccessors(Property): Accessors<StateDictionary[Property]>
-```
-
-where StateDictionary is the value passed to the constructor function and Property is the string passed to `getRootAccessors`. The returned type is an Accessors object with type inferred automatically.
-
-```
-const internalState$ = new ReactiveStore({ dataField: { nestedDataField: "a" }});
-const dataFieldAccessors$ = internalState$.getRootAccessors("dataField");
-```
-
-> When updating values, changes are only applied if they differ from the previous value. If the provided new value is considered the same by the `changeDetector` option (the second parameter of the constructor), the change is ignored at the root and none of the derived values are emitted.
-
-### Accessors
-
-Data Accessors are what we usually call `getters` and `setters`, but here we extend the concept by also including the reactive rxjs `observable`. When calling `getRootAccessors` for a specific field, you'll get the following object:
-
-```
-type Accessors<T> = {
-  getValue(): T;
-  setValue(v: T): void;
-  observable: RXJS.Observable<T>;
-  // propertyName helps debugging what field the accessors are for.
-  // It has no functionality
-  propertyName: string;
-}
-```
-
-You can as well go deeper and recursively create new accessors from existing accessors with the static method
-
-```
-ReactiveStore::mkPropertyAccessors(Accessors<OriginData>, {
-  propertyName: Property
-}): Accessors<OriginData[Property]>`
-```
-
-```
-const internalState$ = new ReactiveStore({ dataField: { nestedDataField: "a" }});
-const dataField$ = internalState$.getRootAccessors("dataField");
-const nestedDataField$ = ReactiveStore.mkPropertyAccessors(dataField$, {
-  propertyName?: "nestedDataField"
-});
-```
-
-<b style="color: red">TODO: </b> Allow `getRootAccessors` to accept a dot notation path in the parameter `propertyName`, which returns nested accessors, removing the need to call a different method for root and nested fields.
-
-### ReadonlyAccessors
-
-Not all data originated from a state dictionary is a simply a value read from a property directly. Some fields are transformed from one or more existing fields. They have a value "computed" from another value. We may create such values, which will be "readonly", by calling the static method
-
-```
-ReactiveStore::mkComputedAccessors(Accessors<OriginData>, {
-  propertyName?: Property,
-  transformer: (originValue: OriginData) => TransformedData
-}): ReadonlyAccessors<TransformedData>`
-```
-
-where `ReadonlyAccessors` is a subset of `Accessors`
-
-```
-type ReadonlyAccessors<T> = {
-  getValue(): T;
-  observable: RXJS.Observable<T>;
-  // propertyName helps debugging what field the accessors are for.
-  // It has no functionality
-  propertyName: string;
-}
-```
-
-### Accessors of Tuples and Remembering values
-
-<b style="color: red">TODO:</b> Document option `rememberNum` and describe `Accessors<Tuple<T>>`
-
-### Reactivity code style
-
-1. Following RXJS's own style guide, Reactive data, either our **custom Accessors or instances of the ReactiveStore class should contain a trailing dollar sign "$"**, as seen above.
-2. **Computed properties**, which are readonly data extracted and transformed from other reactive data, **should also contain a leading underscore "\_"**.
-
-## TypeScript setup
-
-Even though this is not a Monorepo, the directories `modules`, and `apps/*` each have their own `tsconfig.json` file, making each of them an independent TypeScript project. Each tsconfig.json file extends a common tsconfig.base.json file in the root of the repository, where most of the typescript configuration lies. This pattern ensures each project uses a configuration compatible to the other.
-
-These typescript projects aren't exactly independent and the tsconfig.base.json file actually shares common path aliases
-
-- "@module/_": ["./modules/_"],
-- "@static/_": ["./static/_"],
-- "@frankieone/one-sdk": ["./modules/index.ts"],
-- "@types": ["./types/index.ts"],
-
-These path aliases had to be hard copied into the common/vite.config.ts file until I find a plugin to do this automatically. <b style="color: red">TODO</b>
-
-@frankieone/one-sdk allows the React app to import OneSDK as if it came from npm. What really happens is that typescript maps directly to OneSDK in your local filesystem, allowing for all sorts of development perks, such as change detections for hot reloading and others.
-@module and @static are used by the OneSDK modules to refer to their own resources.
-@types are local types and type utilities available to the entire repository
-
-This configuration doesn't need to be shared as they affect different TS projects separately, so they could be split across the specific tsconfig.json files. Since this works as well and makes the configuration a bit easier to understand, I decided to leave it as is for now. <b style="color: red">TODO</b>
-
-## Dependencies
-
-All dependencies of `modules` are described in the root package.json and contained in the root `node_modules`.
-To avoid conflicts during development, all **dev** dependencies for `apps` were _hoisted_ to the root package.json. If and when there's a dependency conflict, always take note and make sure to resolve it by changing the `apps` dependencies.
-`modules` is the source of truth for our dependencies. Non dev dependencies should be declared in their own package.json.
-
-### Shared dependencies
-
-The shared repository has deep and convoluted dependencies which makes it nearly impossible and undesirable to include the entire shared package into the dependencies of OneSDK. For that reason, the necessary files were hard copied and pasted into different folders in `modules/common/shared/`. These should be eventually replaced with new and cleaner implementations.
-
-## Bundling
-
-The **OneSDK modules and assets** are bundled by webpack as UMD scripts, ready to be loaded and run directly on browsers via cdn servers. On the same `build` script, a second compilation is run by `tsc`, where the typescript compiler generates a folder `dist/esm` where ES Modules are generated along with their respective file declarations. This directory is meant to be deployed to the NPM repository for application development, which still needs to be run on a browser or browser-like environment (Native Webviews).
-
-The Playground `cdn` app is prepared for deployment using Vite and generates index.html, index.js and index.css files.
-The `react` app also uses Vite, but so far is only used to validate importing the OneSDK as ES Module. No artifacts are generated for it.
-
-Both `cdn` and `react` mostly share common configurations, defined in `apps/common/vite.config.js`.
-
-Each of these bundlers need to be aware of Typescript paths described in **Typescript setup**, otherwise they are not going to work once built.
-
-- For the main OneSDK bundler, we use webpack.config.js with a resolution plugin `TsConfigPathsPlugin`
-- For react and cdn apps, we use a common bundler configuration in `apps/common/vite.config.js`, with paths manually defined (which could be also simplified with a plugin, but this is good enough for now) <b style="color: red">TODO</b>
-
-## Getting started
-
-Before attempting to install anything, you'll need access to some of our common @frankieone npm packages. For that, please request someone in the frontend team to generate a [npm access token](https://docs.npmjs.com/about-access-tokens) for you. You should set it up, so it will always load into your terminals. For [macOS](https://youngstone89.medium.com/setting-up-environment-variables-in-mac-os-28e5941c771c) and [windows](https://geekflare.com/system-environment-variables-in-windows/). If you use linux, you already know what to do.
-
-The following script will make sure you get a fresh install, by removing any existing `dist` and `node_modules` folders and running `npm install` again in all folders.
-
-```
-npm run fresh
-```
-
-## Environment variables
-
-Ideally, don't include environment variables in the OneSDK modules at all. Environment variables will be bundled with the final UMD build, but will need to be specified for usage with ES Modules, which will be imported and bundled in a foreign environment, with its own variables. In case environment variables are required, make sure to document them in the OneSDK public documentation, so developers can include them into their own environment.
-
-Add all env variables to the root .env files. Only variables with the `PUBLIC_` prefix will be available to `apps`. Don't forget that environment variables will be discoverable in the UMD files once the OneSDK modules are bundled, so never use secrets anywhere in the `modules` source code, **except during local development, as it might be necessary for testing**.
-
-**TODO: create a `SECRET_` prefix that is only used during development**.
-
-If you commit them by mistake, make sure to tell someone, so we can deactivate any access given to the corresponding secret keys. Make sure to add any new environment variable to the type declaration `env.d.ts`, for intelisense and typescript support. Also use that file as a guide of which variables are expected, similar to the usual `.env.example`.
-
-### Accessing Environment variables
-
-~~To keep our codebase according to modern practices and latest standards, this package's internal modules are defined as EcmaScript modules by default (in `package.json > type`). Throughout the entire codebase we will access environment variables through the `import.meta.env`, described [here](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/import.meta) and [here](https://vitejs.dev/guide/env-and-mode.html).~~
-
-There's still not a common modern standard of how to access environment variables when using ES Modules, so for a broader compatibility we will keep using the usual `process.env` global variable.
-
-Since our Javascript codebase is of type `module` (package.json > type), other advanced `import.meta` variables, such as `import.meta.url` are available at build time.
-
-## OneSDK Playground
-
-The Playground is where we can work on and validate features being developed. In the future we can also make it available to the Frankie team to test the OneSDK themselves. It's implemented as a React App and imports the OneSDK modules directly from the source code, using the same entry point customers would from the NPM Registry. For that to work, the OneSDK `modules` folder contains two tsconfig files, the main `tsconfig.json`, which builds the OneSDK bundle for NPM and `tsconfig.composite.json`, which allows other typescript projects present in the same repo to import it as if they belong to the same project. This is done by adding the `composite: true` option to the latter tsconfig file and by including `"reference":[{ path: "../relative-to/modules/tsconfig.composite.json" }]` in the project that needs access to OneSDK modules locally.
-
-To run the playground you should run the following script
-
-```
-npm run dev
-```
-
-## Content Security Policy
-
-Use the CDN playground during development to find out if a new integration requires special [content security policies](https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP).
-Any request that fails due to missing policy should be added to the list of policies in `apps/cdn/index.html` and then documented in the official OneSDK documentation.
-
-## Build and Release process
-
-We have two types of deployment: `development` and `production`. For both type of deployments, the deployment pipeline will do the following:
-
-1. run tests and type check the code base
-2. build the sdk as both UMD and Typed ESModules into the `dist/umd` and `dist/esm` directories, respectively
-3. build the Playground into `apps/playground/dist` directory
-4. deploy the UMD build to the "assets" S3 bucket, into the namespace defined by either the branch or tag name
-5. deploy the ESM build to npm, with the version defined in package.json
-6. deploy the Playground to the "playground" S3 bucket
-
-The UMD build is done by Webpack, whilst the ESM build is done solely by the Typescript compiler. For that reason, ESM has no extra pre-processing and all `.json` imports need to be converted to `.ts` files exporting the JSON content as Typescript values.
-
-### Development releases
-
-Until we're mature enough to do Continuous Integration and trunk-based flows, Gitflow is the chosen git branching strategy. `development` release types will be triggered from the following development branches:
-
-1. `develop`, where tested and validated code will wait for the release into production (see below)
-2. `feature/*`, new feature work that can be tested independently. You may use its suffix instead of the version name in the CDN url to test features live
-
-The S3 buckets for `development` are suffixed by `.dev`, so `assets.dev.frankiefinancial.io` and `play.dev.frankiefinancial.io`.
-
-While in the `develop` branch, npm releases might be manually triggered in the pipeline. This will cause an `rc` prelease version to be created and pushed to the npm registry. Keep in mind that two subsequent rc releases without a version upgrade will fail, since versions can't be repeated. Whenever intending to release to npm, either in production or RC, always up the version before merging into `develop`.
-
-### Production releases
-
-**WIP** This is not the final release process
-
-Once the `develop` branch is ready to be released, it will have its version tagged appropriately with the following command
-
-```
-npm version \
-            major | minor | patch | premajor | preminor | prepatch \
-            -m "Short release description here"
-
-git push origin develop && git push --tags
-```
-
-And merged into `main`, triggering the pipeline to deploy the build into S3 and npm.
-
-## Debugging
-
-This repository is bundled with the following vscode launch configurations:
-
-### Debug React app
-
-Which executes react app on the browser, stopping the execution at any defined breakpoints
-
-### Debug Jest tests
-
-Runs jest in debug mode
-
-### Debug react app
-
-First run `npm run dev` and then run this debug script. You'll be able to position breakpoints anywhere in the codebase.
-
-## All scripts commented
-
-| Script     | Description                                                                                                       |
-| ---------- | ----------------------------------------------------------------------------------------------------------------- |
-| fresh      | Fresh installs all dependencies and generates the modules/meta.json file.                                         |
-| test       | Run all tests.                                                                                                    |
-| refactor   | Watches for both typescript errors and unit tests failures in parallel. Useful for refactoring code.              |
-| build:dev  | Builds OneSDK in development mode (without minifying it, which allows us to visually debug the build).            |
-| dev        | Runs React app for developing the OneSDK as a module import (with typescript types available and all that).       |
-| dev --dist | Same script as above, but with the --dist option. Runs ESM Javascript from `dist` folder, instead of source code. |
-
-## Scripts you shouldn't call directly, but are used by other scripts in the background
-
-| Script          | Description                                                                                             |
-| --------------- | ------------------------------------------------------------------------------------------------------- |
-| lint:staged     | Runs linting before committing. [More info here.](https://github.com/okonet/lint-staged)                |
-| start:react-app | Runs React app in dev mode. Aliased by script "dev"                                                     |
-| start:cdn-app   | Runs the CDN app in dev mode. Used by script "dev:cdn"                                                  |
-| build           | Builds OneSDK for production, also generating type declarations. This is used by the pipeline.          |
-| watch           | Watches for changes in the OneSDK source code and rebuilds it when one occurs. Used by script "dev:cdn" |
-| watch-tsc       | Watches for changes in the OneSDK source code and type checks it. Used by script "refactor"             |
-| tsc-check       | Runs type check in the entire code base once. Used by the pipeline                                      |
-| eslint-check    | Runs eslint checks in the entire code base once. Used by the pipeline                                   |
-
-## Telemetry
-
-Telemetry is the extraction and storage of analytical information regarding the health and usage the OneSDK. It works by sending a sequence of Event objects assembled by the client side and submitted to BFF `POST /events` endpoint, which will then store it as an individual record in the `events` SQL database table. In OneSDK, telemetry events are created by emitting the global event `telemetry` from anywhere in the codebase.
-
-### Definition of the telemetry event
-
-Each telemetry event will always contain common details that refer to the overall stats of the environment the OneSDK is beeing run on. Additional data may be provided in the fields:
-
-1. `data`, where details are simply attached to the `data` field of the event record
-2. `error`,
-   1. if error is an instance of the native JS class `Error`, it will extract `message` and `stack` and assign them to an `error` object inside the event record's `data` field
-   2. if error is an instance of the JS class `OneSDKError`, which extends the native class `Error`, then besides extracting the same as point 1, it also extracts extra details from the `payload` field, provided to `OneSDKError` constructor
-      1. `OneSDKError(message: string, payload: unknown)`, where `payload` may be anything
-   3. if error is anything else, we'll try to break it down into a serialisable object. This is only to prevent missing important information and shouldn't be used explicitly.
-
-If no additional data is required, then you may pass a string representing the eventName directly. See last example below.
-
-```typescript
-telemetry: [string | { eventName: string; data?: TelemetryEvent["data"]; error?: Error }];
-```
-
-Example of telemetry event for the event `INIT`
-
-```typescript
-globalEventHub.emit("telemetry", {
-  eventName: "INIT",
-  data: { mode: sharedState.mode, recipe: sharedState.recipe, warnings },
-});
-```
-
-Example of telemetry event for the event `INIT:ERROR`
-
-```typescript
-globalEventHub.emit("telemetry", {
-  eventName: "INIT:ERROR",
-  data: {
-    oneSdkOptions,
-  },
-  error,
-});
-```
-
-Example of telemetry event for the event `OCR:RESULTS`, which doesn't contain any additional data
-
-```typescript
-globalEventHub.emit("telemetry", "OCR:RESULTS");
-```
-
-## Test Coverage
-
-### Ignoring files for test coverage
-
-It won't make sense to add coverage to some files. In those circumstances, either simply add the following comment to the top of the file:
-
-```typescript
-/* istanbul ignore file */
-```
-
-OR add a negation pattern **to the end** of the `collectCoverageFrom` option in `jest.config.js`
-
-```javascript
-collectCoverageFrom: ["modules/**/*.ts", "!**/__*.ts"];
-```
-
-## "Cannot use import statement outside a module" and other similar nonsense when running Jest tests
-
-```
-npx jest --clearCache
-```
-
-## TODO
-
-- [x] Refactor `modules/sdk` directory to follow the directions for regular components
-- [ ] Decide which files to keep and cleanup legacy files from old setup (such as rollup.config.js)
-- [x] Setup npm deployment
-- [ ] Install commitzen
-- [ ] Publish documentation with version log from commitzen
-- [x] Production deployments
-  - [x] CDN
-  - [x] NPM
-- [ ] Document caching for assynchronous modules
-- [ ] Find out browser compatibility and declare in package.json and in the documentation
-- [ ] **Auto unregister all events when closing the one sdk**
-- [ ] Avoid duplicated code with https://www.typescriptlang.org/tsconfig#importHelpers
+https://apidocs.frankiefinancial.com/docs/about-onesdk

package/dist/commit.txt

@@ -1,2 +1,2 @@
-89f3802a120e0ea6bb6fca58eb99daf22b86bd6b
-89f3802a120e0ea6bb6fca58eb99daf22b86bd6b
+959fe7d04c6a39b550f351960cfdd5cad7fe4b23
+959fe7d04c6a39b550f351960cfdd5cad7fe4b23

package/dist/esm/modules/biometrics/wrappers/OcrLabs/index.js

@@ -54,60 +54,71 @@ const mountUserInterface = (options) => {
     const mountElement = originalElement.cloneNode(true);
     originalElement.parentNode.replaceChild(mountElement, originalElement);
     mountElement.id = "onesdk_idv_container";
-    mountElement.style.height = "100%";
-    mountElement.style.minHeight = "50px";
-    mountElement.style.width = "100%";
-    mountElement.style.position = "absolute";
-    mountElement.style.top = "0";
-    mountElement.style.left = "0";
-    mountElement.style.overflow = "hidden";
-    mountElement.style.backgroundColor = "#000";
+    Object.assign(mountElement.style, {
+        height: "100%",
+        minHeight: "50px",
+        width: "100%",
+        position: "absolute",
+        top: "0",
+        left: "0",
+        overflow: "hidden",
+        backgroundColor: "#000",
+    });
     const loader = document.createElement("div");
     loader.id = "onesdk_idv_loader";
-    loader.style.position = "absolute";
-    loader.style.top = "20px";
-    loader.style.left = "50%";
-    loader.style.transform = "translate(-50%, 0)";
-    loader.style.color = "#fff";
-    loader.style.fontFamily = '"Helvetica Neue", Helvetica, Arial, sans-serif';
-    loader.style.fontSize = "24px";
+    Object.assign(loader.style, {
+        position: "absolute",
+        top: "20px",
+        left: "50%",
+        transform: "translate(-50%, 0)",
+        color: "#fff",
+        fontFamily: '"Helvetica Neue", Helvetica, Arial, sans-serif',
+        fontSize: "24px",
+    });
     loader.innerText = "Loading...";
     mountElement.appendChild(loader);
     const videoElement = document.createElement("video");
     videoElement.id = "onesdk_idv_video";
     videoElement.autoplay = true;
     videoElement.muted = true;
-    videoElement.style.position = "absolute";
-    videoElement.style.top = "0";
-    videoElement.style.left = "0";
     videoElement.playsInline = true;
-    videoElement.style.height = "100%";
-    videoElement.style.width = "100%";
-    videoElement.style.display = "none";
-    videoElement.style.zIndex = "1";
-    videoElement.style.objectFit = "cover";
+    Object.assign(videoElement.style, {
+        position: "absolute",
+        top: "0",
+        left: "0",
+        height: "100%",
+        width: "100%",
+        display: "none",
+        zIndex: "1",
+        objectFit: "cover",
+        transform: "scale(-1,1)", // mirror the video element
+    });
     mountElement.appendChild(videoElement);
     const overlayContainer = document.createElement("div");
     overlayContainer.id = "onesdk_idv_overlay";
-    overlayContainer.style.position = "absolute";
-    overlayContainer.style.top = "0";
-    overlayContainer.style.left = "0";
-    overlayContainer.style.height = "100%";
-    overlayContainer.style.width = "100%";
-    overlayContainer.style.display = "none";
-    overlayContainer.style.zIndex = "2";
+    Object.assign(overlayContainer.style, {
+        position: "absolute",
+        top: "0",
+        left: "0",
+        height: "100%",
+        width: "100%",
+        display: "none",
+        zIndex: "2",
+    });
     overlayContainer.appendChild(createOverlay("white"));
     mountElement.appendChild(overlayContainer);
     const instructions = document.createElement("div");
     instructions.id = "onesdk_idv_instructions";
-    instructions.style.position = "absolute";
-    instructions.style.bottom = "20px";
-    instructions.style.left = "50%";
-    instructions.style.transform = "translate(-50%, 0)";
-    instructions.style.color = "#fff";
-    instructions.style.fontFamily = '"Helvetica Neue", Helvetica, Arial, sans-serif';
-    instructions.style.fontSize = "24px";
-    instructions.style.zIndex = "3";
+    Object.assign(instructions.style, {
+        position: "absolute",
+        bottom: "20px",
+        left: "50%",
+        transform: "translate(-50%, 0)",
+        color: "#fff",
+        fontFamily: '"Helvetica Neue", Helvetica, Arial, sans-serif',
+        fontSize: "24px",
+        zIndex: "3",
+    });
     mountElement.appendChild(instructions);
     loadOcrLabs(options);
     return videoElement;
@@ -126,7 +137,9 @@ const cleanup = (options) => __awaiter(void 0, void 0, void 0, function* () {
         eventHub.emit("error", new OneSDKError("Error from vendor SDK 'OcrLabs'", {
             message,
         }));
+        return false;
     }
+    return true;
 });
 const loadOcrLabs = (options) => __awaiter(void 0, void 0, void 0, function* () {
     const idvClient = new IDVClient(options.frankieClient);
@@ -216,7 +229,8 @@ const runLivenessChecks = (options, idvClient) => __awaiter(void 0, void 0, void
     yield handleDetection("smile", "Please give us a BIG Smile!");
     eventHub.emit("detection_complete");
     try {
-        yield cleanup(options);
+        if (!(yield cleanup(options)))
+            return; // escape initProcess if cleanup failed
         const { checkStatus } = yield idvClient.initProcess({ isSynchronous: !!isSynchronous });
         switch (checkStatus) {
             case Status.PROVIDER_OFFLINE: {