@digitalpersona/authentication - npm Package Compare versions

Comparing version 0.2.3 to 0.2.4

api-extractor.json

@@ -125,3 +125,3 @@ /**
      */
-    "reportFolder": "<projectFolder>/docs/api/",
+    "reportFolder": "<projectFolder>/dist/api/",
 
@@ -186,3 +186,3 @@ /**
      */
-    // "untrimmedFilePath": "<projectFolder>/dist/<unscopedPackageName>.d.ts",
+    // "untrimmedFilePath": "<projectFolder>/dist/api/<unscopedPackageName>.d.ts",
 
@@ -199,3 +199,3 @@ /**
      */
-    // "betaTrimmedFilePath": "<projectFolder>/dist/<unscopedPackageName>-beta.d.ts",
+    // "betaTrimmedFilePath": "<projectFolder>/dist/api/<unscopedPackageName>-beta.d.ts",
 
@@ -215,3 +215,3 @@
      */
-    // "publicTrimmedFilePath": "<projectFolder>/dist/<unscopedPackageName>-public.d.ts",
+    // "publicTrimmedFilePath": "<projectFolder>/dist/api/<unscopedPackageName>-public.d.ts",
   },
@@ -218,0 +218,0 @@

docs/index.md

@@ -1,18 +0,55 @@
-# JavaScript Client for DigitalPersona Authentication
+---
+layout: default
+title: Overview
+has_toc: false
+nav_order: 1  
+---
+{% include header.html %}
 
-This library allows web browsers to identify and authenticate users with various credentials
-using DigitalPersona Access Management services.
+# Overview
 
-## [Usage](use/index.md)
-* [Details](use/details.md)
-* [Tutorial](use/tutorial.md)
-* [How-to](use/how-to.md)
-* [Reference](use/reference.md)
+{% include dpam-intro.md %}
 
-## [Information for maintainers](maintain/index.md)
-* [Build](maintain/build.md)
-* [Test](maintain/test.md)
-* [Code](maintain/code.md)
-* [Document](maintain/document.md)
-* [Version](maintain/version.md)
-* [Deploy](maintain/deploy.md)
+As a part of {{ site.data.product.shortName }}, the {{ site.data.lib.name }}
+allows you to strengthen your web application security with multicactor authentication (MFA) 
+seamlesly working with various authentication devices like fingerprint readers, card readers,
+cameras for face recognition, FIDO tokens, OTP tokens, as well as with traditional credentials
+like password, PIN or security questions.
+
+## Dependencies
+
+The library depends on 
+* DigitalPersona Web Services API
+* DigitalPersona Core API
+
+It also requires DigitalPersona Web Components and DigitalPersona Authentication Server
+running in your security domain.
+
+Some authentication tokens (fingerprints, cards, U2F, Integrated Windows Authentication) 
+require DigitalPersona Device Access API to read authentication data from a device and pass it
+the {{ site.data.lib.shortName }}.
+
+## Requirements
+
+{% include reqs/platforms.md %}
+
+{% include reqs/languages.md %}
+
+### Browser support
+
+{% include shims/promise.md %}
+
+{% include shims/fetch.md %}
+
+### Node JS support
+
+{% include shims/node-base64.md %}
+
+{% include shims/node-fetch.md %}
+
+## Additional documentation:
+
+* [Tutorial](./tutorial.md)
+* [How-to](./how-to.md)
+* [Reference](./reference.md)
+* [Library Maintenance](./maintain/index.md)

docs/maintain/build.md

@@ -0,7 +1,16 @@
+---
+layout: default
+title: Making a build
+has_toc: false
+nav_exclude: true
+---
+{% include header.html %}
+
 # Making a build
 
 <a name="toolchain"></a>
-## Prepare a toolchain
+## Preparing a toolchain
 
-The library uses a following toolchain:
+The library uses the following toolchain:
+
 * [Node JS](https://nodejs.org) with NPM (NodeJS Package Manager).
@@ -13,3 +22,3 @@ * [yarn](https://yarnpkg.com) Package Manager.
 
-First install NodeJS with NPM, then install the rest of the toolchain globally using NPM:
+First install NodeJS with NPM, then install the rest of the toolchain globally using NPM.
 
@@ -26,3 +35,3 @@ ```
 ```
-git clone https://github.com/hidglobal/digitalpersona-core.git
+git clone {{site.data.lib.git}}/{{-site.data.lib.repo-}}.git
 ```
@@ -33,7 +42,6 @@
 
-
 To get started with the library, install dependencies first:
 
 ```
-cd ./digitalpersona-authentication
+cd ./{{site.data.lib.repo}}
 yarn
@@ -43,3 +51,3 @@ ```
 <a name="code"></a>
-## Build code
+## Building the code
 
@@ -54,3 +62,3 @@ Build the library:
 
-The build output (JavaScript files) will be put into following locations, according to a target:
+The build output (JavaScript files) will be put into the following locations, according to the target:
 * ES6 (for modern browsers):
@@ -65,3 +73,3 @@ * unbundled: `./dist/es6/`
 <a name="documentation"></a>
-## Build documentation
+## Building the documentation
 
@@ -71,3 +79,3 @@ API documentation is built from source code comments in a TSDoc format
 
-To build API documentation run:
+To build the API documentation run:
 ```
@@ -77,12 +85,12 @@ npm run api-doc
 
-The build output (Markdown files) will be put into a `./docs/api/` folder.
+The build output (API report files and Markdown documents) will be put into the `./dist/api/` folder.
 
 ## Build pipeline overview
 
-
 [![Build pipeline](build-pipeline.svg)](build-pipeline.dot)
 
-> NOTE: this diagram is created using Graphviz and a `build-pipeline.dot` file.
+<small>NOTE: this diagram is created using Graphviz and a `build-pipeline.dot` file.
 Do not edit the SVG file directly.
-In VS Code, use [Graphviz Preview](https://marketplace.visualstudio.com/items?itemName=EFanZh.graphviz-preview)
+In VS Code, use the [Graphviz Preview](https://marketplace.visualstudio.com/items?itemName=EFanZh.graphviz-preview)
 extension to preview DOT files and export them to SVG/PNG/PDF.
+</small>

docs/maintain/code.md

@@ -1,5 +0,13 @@
-# Coding Guides
+---
+layout: default
+title: Coding Guidelines
+has_toc: false
+nav_exclude: true
+---
+{% include header.html %}
 
-The library uses the TypeScript as a main language. It is transpiled to Javascript (`es5` and `es6` platforms).
+# Coding Guidelines
 
+This library uses TypeScript as the primary coding  language. It is transpiled to Javascript (`es5` and `es6` platforms).
+
 ## Library size
@@ -11,44 +19,53 @@
 
-The library tries to follow the most modern ECMAScript standards, but support of `es5` platform put some restrictions.
-The rules of thumb are:
+The library attempts to follow the most modern ECMAScript standards, but support for the `es5` platform put incurs some restrictions.
 
-* If there is a modern ECMAScript API which has `es5` shims available, prefer to follow the modern standard and let
-the end user to provide a shim.
-* If there is modern ECMAScript syntax which can be transpiled to `es5` without large overhead, use the newer syntax, 
-  otherwise use the older equivalent.
+Rules of thumb are:
 
+* If there is a modern ECMAScript API which has `es5` shims available, prefer to follow the modern standard and let the end user provide a shim.
+* If there is modern ECMAScript syntax which can be transpiled to `es5` without a large overhead, use the newer syntax, otherwise use the older equivalent.
+
 ### ES6 Async/await syntax
 
-Despite the recommendations to use `async/await` pattern everywhere, we avoid it in the main library code and prefer
-`promise().then().catch()` pattern instead. This allows us to reduce es5-transpiled code size, avoiding overhead of 
-a quite large (~1.5Kb minified) `generator/awaiter` shim inserted by TypeScript.
+Despite a recommendation to use the `async/await` pattern everywhere, we avoid it in the main library code and prefer the `promise().then().catch()` pattern instead. This allows us to reduce the size of es5-transpiled code, avoiding a rather large (~1.5Kb minified) overhead of the `generator/awaiter` shim inserted by TypeScript.
 
-This policy can be reviewed after support of `es5` platform is dropped.
+This policy can be reviewed should support of `es5` platform be dropped.
 
-It is still recommended to use the `async/await` pattern in unit tests, as code size is not critical here.
+It is still recommended to use the `async/await` pattern in unit tests, as code size is not critical there.
 
 ### ES6 Object Spread syntax
 
-The ES6 object spread syntax adds an overhead to the es5-transpiled code, but it is negligible comparing to the manual
-object merging, so it is ok to use it.
+The ES6 object spread syntax adds an overhead to the es5-transpiled code, but it is negligible compared to the manual object merging, so it is ok to use it.
 
 ## Modular design
 
-The library uses TypeScript/ES2015 module system. You must understand what modules are and are not.
+The library uses the TypeScript/ES2015 module system. It is critical to understand what modules are and are not.
 
-**Do not use namespaces!** Module is a "namespace" by itself because the module consumer will give
-a named scope for all exports of the module, e.g: `import * as shapes from './Shapes'` or `var shapes = require('./Shapes')`.
+### Do not use namespaces!
+
+Module is a "namespace" by itself because the module consumer will give a named scope for all exports of the module, e.g: `import * as shapes from './Shapes'` or `var shapes = require('./Shapes')`.  
+
 There is no need to create your own namespaces in the library.
 
-**Keep every module as small as possible!** It is ok to have a single export class/enum/interface per module. 
+### Keep every module as small as possible!
+
+It is ok to have a single export class/enum/interface per module.  
+
 This allows "tree-shaking" algorithms to work more effectively when the final JS bundle is created, 
-thus potentially reducing the size of the bundle. To avoid long imports you can group several modules 
-in a larger super-module using a "barrel" module approach: create an `index.ts` file which re-exports
-every sub-module, and you can import the `index.ts` instead of individual sub-modules.
+thus potentially reducing the size of the bundle.  
 
-**Do not bundle prematurely!** Prefer to keep your modules pure and unbundled, as premature bundling
-may reduce tree-shaking effeciveness. If you deliver your library in formats like `commonjs` or `umd`,
-the benefit is that they are immediately ready to load into a browser, but a downside is that bundlers
-like Webkpack, Browserify, Rollup or Parcel have a hard time to remove unneeded code. As your library consumer
-most probably will use a bundler, it is better to let the end user to generate the bundle from pure ES2015 modules.
+To avoid long imports you can group several modules
+in a larger super-module using a "barrel" module approach, i.e.  
+- Create an `index.ts` file which re-exports
+every sub-module, and
+- Import the `index.ts` instead of the individual sub-modules.
+
+### Do not bundle prematurely!
+
+Prefer to keep your modules pure and unbundled, as premature bundling may reduce tree-shaking effeciveness.  
+
+If you deliver your library in formats like `commonjs` or `umd`, the benefit is that they are immediately ready to load into a browser, but a downside is that bundlers
+like Webkpack, Browserify, Rollup or Parcel have a hard time removing unnecessary code.  
+
+As your library consumer most probably will use a bundler, it is better to let the end user  generate the bundle from pure ES2015 modules.  
+
 The `commonjs` or `umd` modules can be provided as a convenience only and should not be consumed directly.

docs/maintain/deploy.md

@@ -0,5 +1,11 @@
+---
+layout: default
+title: Deployment
+has_toc: false
+nav_exclude: true
+---
+{% include header.html %}
+
 # Deployment
 
 ## NPM
-
-

docs/maintain/document.md

@@ -0,19 +1,22 @@
+---
+layout: default
+title: Documenting Guidelines
+has_toc: false
+nav_exclude: true
+---
+{% include header.html %}
+
 # Documenting Guidelines
 
-All development documentation must be a part of the project source base,
-so they are
-- immediately accessible to developers cloning the repository
-  (no need in external document hosting like Confluence)
-- has a full history tracking
-- documents still can be referred and linked from other web pages
-  via TFS web interface
+All development documentation must be a part of the project source base so that they:
+- are immediately accessible to developers cloning the repository, i.e. not requiring external document hosting on platforms such as Confluence.
+- have full history tracking
+- can easily be referred to and linked from other web pages via the TFS web interface.
 
-Documents preferrable format is Markdown:
-- it is an enriched text format, so developers can easily see diffs in Git
-- it remains readable in any text viewer, even lacking Markdown support.
-- it integrates well with the TFS web interface. The `Readme.md` file is a
-  default documentation enry point in TFS repositories and automaticaly
-  shows up when open TFS web repos in a browser.
+The preferrable format for the documentation is Markdown.
+- It is an enriched text format, so developers can easily see diffs in Git.
+- It remains readable in any text viewer, even those lacking specific Markdown support.
+- It integrates well with the TFS web interface. The `Readme.md` file is a default documentation enry point in TFS repositories and automatically displays when TFS  repos are opened in a web browser.
 
-To learn more about the markdown syntax, refer to these links:
+To learn more about the Markdown syntax, refer to these links.
 
@@ -24,2 +27,1 @@ - [Markdown Syntax Guide](http://daringfireball.net/projects/markdown/syntax)
  - [markdown at wikipedia](https://secure.wikimedia.org/wikipedia/en/wiki/Markdown)
-

docs/maintain/index.md

@@ -1,10 +0,16 @@
-# Information for developers
+---
+layout: default
+title: Library Maintenance
+has_toc: false
+nav_order: 5
+---
+{% include header.html %}
 
+# Library Maintainance
+
 ## Recommended Tools
 
-Recommended **package manager** is [yarn](https://yarnpkg.com). While `npm` can be also used, sometimes
-is gets broken and requires deleting the whole `node_modules` folder and all lock files and reinstall
-all packages.
+Recommended **package manager** is [yarn](https://yarnpkg.com). While `npm` can be also used, we find that it occasionally breaks and requires deleting the whole `node_modules` folder and all lock files and reinstalling all packages.
 
-Recommended **IDE** is [Microsoft VS Code](https://code.visualstudio.com/), with folowing extensions:
+The recommended **IDE** is [Microsoft VS Code](https://code.visualstudio.com/), with the following extensions:
 
@@ -16,13 +22,11 @@ * [NPM Support for VS Code](https://marketplace.visualstudio.com/items?itemName=eg2.vscode-npm-script)
 
-Recommended **local NPM registry** is [Verdaccio](https://verdaccio.org/). Very simple to install
-and configure, it allows you to test publishing of NPM modules locally, without exposing your unfinished
-work to the whole world.
+The recommended **local NPM registry** is [Verdaccio](https://verdaccio.org/). It is very simple to install and configure, and it allows you to test publishing of NPM modules locally without exposing your unfinished work to the whole world.
 
 ## Development Guides
 
-* [Code](code.md)
-* [Build](build.md)
-* [Test](test.md)
-* [Document](document.md)
-* [Version](version.md)
-* [Deploy](deploy.md)
+* [Coding](code.md)
+* [Building](build.md)
+* [Testing](test.md)
+* [Documenting](document.md)
+* [Versioning](version.md)
+* [Deploying](deploy.md)

docs/maintain/test.md

@@ -0,1 +1,9 @@
+---
+layout: default
+title: Testing
+has_toc: false
+nav_exclude: true
+---
+{% include header.html %}
+
 # Testing
@@ -2,0 +10,0 @@

docs/maintain/version.md

@@ -0,1 +1,9 @@
+---
+layout: default
+title: Versioning Guidelines
+has_toc: false
+nav_exclude: true
+---
+{% include header.html %}
+
 # Package Versioning Guidelines
@@ -9,3 +17,3 @@
 
-* Change `Major` when braking changes are introduced.
+* Change `Major` when breaking changes are introduced.
 * Change `Minor` when new functionality is added, but backvard compatibility is preserved.
@@ -15,3 +23,1 @@ * Change `Patch` when existing functionalty is fixed, no new functionality is added
 * Set `Stage` to `-alpha`, `-beta`, `-pre` etc for prereleases. Remove `Stage` for releases.
-
-

package.json

 {
   "name": "@digitalpersona/authentication",
   "globalObject": "dp.authentication",
-  "version": "0.2.3",
+  "version": "0.2.4",
   "repository": {
@@ -52,3 +52,3 @@ "type": "git",
     "clean": "rimraf ./dist",
-    "build": "npm run clean && npm run tsc-all && npm run rollup",
+    "build": "npm run clean && npm run tsc-all && npm run rollup && npm run api && npm run api-doc",
     "tsc": "tsc",
@@ -65,6 +65,6 @@ "tsc-es5": "tsc --p ./build/tsconfig/tsconfig.es5.json",
     "test-once": "karma start --single-run",
-    "api": "mkdirp ./docs/api/ && rimraf ./dist/api && npx api-extractor run --local --verbose",
-    "api-doc": "tsc && npm run api && npx api-documenter markdown -i ./dist/api -o ./docs/api",
-    "api-all": "npm run api && npm run api-doc",
     "local-npm": "start verdaccio",
+    "api": "npx api-extractor run --local --verbose",
+    "api-doc": "npx api-documenter markdown -i ./dist/api -o ./dist/api/docs",
+    "api-all": "tsc && npm run api && npm run api-doc",
     "prepublishOnly": "npm run build"
@@ -77,23 +77,25 @@ },
   },
-
   "devDependencies": {
-    "@types/jasmine": "^3.3.9",
-    "@types/node": "^12.0.0",
-    "jasmine": "^3.3.1",
-    "jasmine-core": "^3.3.0",
-    "karma": "^4.0.1",
-    "karma-chrome-launcher": "^2.2.0",
-    "karma-ie-launcher": "^1.0.0",
-    "karma-jasmine": "^2.0.1",
-    "karma-typescript": "^4.0.0",
-    "mkdirp": "^0.5.1",
-    "rimraf": "^2.6.3",
-    "rollup": "^1.6.0",
-    "rollup-plugin-node-resolve": "^4.0.1",
-    "rollup-plugin-terser": "^4.0.4",
-    "rollup-plugin-typescript2": "^0.21.0",
-    "terser": "^3.17.0",
-    "tslint": "^5.14.0",
-    "typescript": "^3.4.5"
+    "@types/jasmine": "^3.3",
+    "@types/node": "^12.0",
+    "jasmine": "^3.4",
+    "jasmine-core": "^3.3",
+    "karma": "^4.0",
+    "karma-chrome-launcher": "^2.2",
+    "karma-ie-launcher": "^1.0",
+    "karma-jasmine": "^2.0",
+    "karma-typescript": "^4.0",
+    "mkdirp": "^0.5",
+    "rimraf": "^2.6",
+    "rollup": "^1.6",
+    "rollup-plugin-node-resolve": "^4.0",
+    "rollup-plugin-terser": "^4.0",
+    "rollup-plugin-typescript2": "^0.21",
+    "terser": "^3.17",
+    "tslint": "^5.14",
+    "typescript": "^3.5"
+  },
+  "resolutions": {
+    "lodash": "^4.17.13"
   }
 }

No alert changes

Improved metrics

Total package byte prevSize

930659

increased by16.73%

Number of package files

293

increased by5.4%

Lines of code

9442

increased by67.68%

No dependency changes