Update hypersync-sdk to 6.0.0-beta.1

.eslintrc.js

@@ -1,32 +1,20 @@
+/* eslint-env node */
+
 module.exports = {
-  env: {
-    browser: false,
-    commonjs: true,
-    es2021: true,
-    node: true
-  },
-  extends: [
-    'eslint:recommended',
-    'plugin:@typescript-eslint/recommended',
-    'prettier'
-  ],
-  parserOptions: {
-    ecmaVersion: 'latest'
-  },
-  plugins: ['@typescript-eslint'],
-  rules: {
-    '@typescript-eslint/no-non-null-assertion': 0,
-    '@typescript-eslint/ban-types': 0,
-    '@typescript-eslint/explicit-module-boundary-types': ['off'],
-    '@typescript-eslint/no-explicit-any': ['off']
-  },
+  ignorePatterns: ['src/**/*.test.ts'],
   overrides: [
     {
-      files: ['*.js'],
+      files: ['*.ts'],
+      parser: '@typescript-eslint/parser',
+      parserOptions: {
+        ecmaVersion: 'latest',
+        project: `${__dirname}/tsconfig.json`
+      },
       rules: {
-        '@typescript-eslint/no-var-requires': 'off'
+        'max-lines-per-function': ['error', { max: 570, skipBlankLines: true }],
+        'max-depth': ['error', 6],
+        complexity: ['error', 25]
       }
     }
-  ],
-  ignorePatterns: ['**/build/*']
+  ]
 };

.github/workflows/build.yml

@@ -0,0 +1,26 @@
+name: CI
+
+on:
+  push:
+    branches: [main]
+  pull_request:
+    branches: [main]
+
+jobs:
+  build:
+    runs-on: ubuntu-latest
+
+    steps:
+      - uses: actions/checkout@v4
+
+      - name: Setup Node.js
+        uses: actions/setup-node@v4
+        with:
+          node-version: '22'
+          cache: 'yarn'
+
+      - name: Install dependencies
+        run: yarn install --frozen-lockfile
+
+      - name: Build
+        run: yarn build

doc/001-getting-started.md

@@ -8,11 +8,11 @@ Every Hypersync app is a [Node.js](https://nodejs.org/en/) [module](https://node
 
 To use the Hypersync SDK you will need a Windows, Mac or Linux computer with a few software packages installed.
 
-Since each Hypersync is a Node.js module, you will need to have Node.js installed in order to build custom Hypersyncs. The Hypersync platform uses Node.js version 16 which you can install here:
+Since each Hypersync is a Node.js module, you will need to have Node.js installed in order to build custom Hypersyncs. The Hypersync platform uses Node.js version 22 which you can install here:
 
-- [Node JS version 18](https://nodejs.org/download/release/v18.17.1/).
+- [Node.js](https://nodejs.org/en/download).
 
-You will also need to install the classic yarn package manager (version 1.22.19) using the link below.
+You will also need to install the classic yarn package manager using the link below:
 
 - [yarn package manager](https://classic.yarnpkg.com)
 
@@ -22,15 +22,14 @@ The Hyperproof CLI is needed to publish and manage your custom Hypersyncs:
 
 Finally, we recommend cloning the [Hypersync SDK Samples GitHub repository](https://github.com/Hyperproof/hypersync-sdk-samples). This is a public repository available on GitHub.com.
 
-- The samples repository contains several complete Hypersync apps that can be used to bring data from an external service into Hyperproof. Using the Hyperysnc SDK you can customize these samples to meet your needs. The hypersync-sdk-samples repository contains samples for MySQL, Zoho and other services. Your will find the these Hypersync apps in the `/apps` directory.
+- The samples repository contains several complete Hypersync apps that can be used to bring data from an external service into Hyperproof. Using the Hypersync SDK you can customize these samples to meet your needs. The hypersync-sdk-samples repository contains samples for MySQL, Zoho and other services. Your will find the these Hypersync apps in the `/apps` directory.
 
 - The samples repository also includes a handful of templates to get you started building your own Hypersyncs from scatch. Templates can be found in the `/templates` directory. See the `README.md` files in each template directory for more information on using the templates.
 
 ## Sandbox Organization (optional)
 
 For development purposes it is recommended to have a separate 'sandbox' organization in Hyperproof. This will allow you to develop and test your custom Hypersync apps in isolation without affecting the users in your production Hyperproof organization. To create a 'sandbox' organization, please contact your Hyperproof Customer Service Manager.
 
-
 ## Next Steps
 
 Once you have installed the prerequisites and determined the organization that you will use for development, you are ready to install your first custom Hypersync app. Follow the guidance in [App Development Workflow](./002-dev-workflow.md) to install, test and update one of the pre-built sample apps.

doc/002-dev-workflow.md

@@ -15,16 +15,14 @@ After installing the CLI, you will first need to sign in using this command:
 ```
 hp signin
 ```
->  NOTE: For customers using Hyperproof EU or Hyperproof GOV, please use the following commands:
+
+> NOTE: For customers using Hyperproof EU, please use the following command:
+>
+> ```
+> hp signin --domain hyperproof.eu
+> ```
 >
->```
->hp signin --domain hyperproof.eu
->```
->or
->```
->hp signin --domain hyperproofgov.app
->```
->For additional information use 'hp signin -help'
+> For additional information use 'hp signin -help'
 
 This command will launch a new browser window and allow you to sign in (if you are not already signed in) and then authorize CLI access to your Hyperproof organization.
 
@@ -34,7 +32,7 @@ This command will launch a new browser window and allow you to sign in (if you a
 
 ### Importing Your Hypersync App
 
-Once you have signed in and authorized the CLI, you are ready to import a custom Hyperysnc app.
+Once you have signed in and authorized the CLI, you are ready to import a custom Hypersync app.
 
 1. Find the `apps/open-library/` directory in your clone of the Hypersync SDK Samples repository.
 2. Make a copy of that folder somewhere else on your computer. Feel free to rename the folder if that helps.

doc/004-connections.md

@@ -24,8 +24,9 @@ In a Hypersync app, there are two types connections: [OAuth connections](#oauth-
 > a [custom authentication connection](#custom-authentication) should be used.
 
 > **NOTE: API Permissions**
->- Always use the minimum permissions necessary for proofs. Hypersyncs are read-only so use read-only permissions when possible.
->- Use minimum scopes when using OAuth. The Hypersync author is going to be asked to authorize one or more scopes. You only want to ask for what you need.
+>
+> - Always use the minimum permissions necessary for proofs. Hypersyncs are read-only so use read-only permissions when possible.
+> - Use minimum scopes when using OAuth. The Hypersync author is going to be asked to authorize one or more scopes. You only want to ask for what you need.
 
 ## OAuth Authorization
 
@@ -92,7 +93,7 @@ Finally, implement the `getUserId` and `getUserAccountName` methods. `getUserId`
 
 ## Custom Authentication
 
-All non-OAuth authentication/authorization schemes are classified as "Custom" in the Hyperysnc SDK. If your service does not use OAuth 2.0, you should specify `custom` as your `authType` in `package.json`. See [Custom Hypersync App package.json Reference](./030-package-json-reference.md) for more information.
+All non-OAuth authentication/authorization schemes are classified as "Custom" in the Hypersync SDK. If your service does not use OAuth 2.0, you should specify `custom` as your `authType` in `package.json`. See [Custom Hypersync App package.json Reference](./030-package-json-reference.md) for more information.
 
 Custom auth covers any type of authentication where the user provides credentials to make a connection. Credentials can include user name/password, access key/secret key, API Token, and many others. Users may also need to designate the endpoint they’re connecting to - for example by providing a URL or a region.
 

doc/005-data-sources.md

@@ -6,7 +6,7 @@ Data sources can retrieve different data sets from the external service. Each da
 
 Data set names are used in other components like proof types to identify the specific data element or elements needed by that component.
 
-> **NOTE**: Data sets can and *should* be re-used across multiple proof types, and can also be used in non-proof scenarios such as collecting user data during the `validateCredentials` process.
+> **NOTE**: Data sets can and _should_ be re-used across multiple proof types, and can also be used in non-proof scenarios such as collecting user data during the `validateCredentials` process.
 
 ## REST Data Sources
 
@@ -66,9 +66,9 @@ For more information on configuring the data sets in your data source using `dat
 
 Many REST APIs use a paging mechanism to allow data to be retrieved in chunks. For example, some APIs take a `pageSize` and `pageNumber` argument which specify how many items to return, and the page number to start reading from, respectively.
 
-Four paging styles are supported: __Page Based__, __Offset And Limit__, __Next Token__, and __GraphQL Connections__.  As a default, query string parameters will be programatically added to an API url.  If POST is designated as the data source HTTP method, paging parameters are added to the body of the request.
+Four paging styles are supported: **Page Based**, **Offset And Limit**, **Next Token**, and **GraphQL Connections**. As a default, query string parameters will be programatically added to an API url. If POST is designated as the data source HTTP method, paging parameters are added to the body of the request.
 
-1.  __Page Based.__  Begin paging at a starting value and increment the page value by 1 after each iteration (1, 2, 3, etc).  Return at most `limitValue` items per page.
+1.  **Page Based.** Begin paging at a starting value and increment the page value by 1 after each iteration (1, 2, 3, etc). Return at most `limitValue` items per page.
 
 ```json
 "pagingScheme": {
@@ -83,9 +83,9 @@ Four paging styles are supported: __Page Based__, __Offset And Limit__, __Next T
 }
 ```
 
-The mandatory `request` property in the paging scheme constructs the paged query string.  The query string of the first API call from the above example will be: `?pageNumber=1&pageSize=100`.  Each paging scheme must include a `pageUntil` property which defines the point at which pagination stops.  If `reachTotalCount` condition is applied, `totalCount` must be defined in the response object, which represents the path to the total combined number of items in the data returned from the external service.*
+The mandatory `request` property in the paging scheme constructs the paged query string. The query string of the first API call from the above example will be: `?pageNumber=1&pageSize=100`. Each paging scheme must include a `pageUntil` property which defines the point at which pagination stops. If `reachTotalCount` condition is applied, `totalCount` must be defined in the response object, which represents the path to the total combined number of items in the data returned from the external service.\*
 
-2.  __Offset And Limit.__  Begin paging at a starting value and increment the offset by the number of elements in a full page (0, 100, 200, 300, etc).  Return at most `limitValue` items per page.
+2.  **Offset And Limit.** Begin paging at a starting value and increment the offset by the number of elements in a full page (0, 100, 200, 300, etc). Return at most `limitValue` items per page.
 
 ```json
 "pagingScheme": {
@@ -103,9 +103,9 @@ The mandatory `request` property in the paging scheme constructs the paged query
 }
 ```
 
-The mandatory `request` property in the paging scheme constructs the paged query string.  The query string of the first API call from the above example will be: `?offset=0&limit=100`.  Each paging scheme must include a `pageUntil` property which defines the point at which pagination stops.  If `reachTotalCount` condition is applied, `totalCount` must be defined in the response object.  This string value represents the path to the total combined number of items in the data returned from the external service.*
+The mandatory `request` property in the paging scheme constructs the paged query string. The query string of the first API call from the above example will be: `?offset=0&limit=100`. Each paging scheme must include a `pageUntil` property which defines the point at which pagination stops. If `reachTotalCount` condition is applied, `totalCount` must be defined in the response object. This string value represents the path to the total combined number of items in the data returned from the external service.\*
 
-3.  __Next Token.__  Begin paging and continue until `nextToken` is no longer provided.  Return at most `limitValue` items per page.  Tokens may be a unique string returned from the external service or a url.
+3.  **Next Token.** Begin paging and continue until `nextToken` is no longer provided. Return at most `limitValue` items per page. Tokens may be a unique string returned from the external service or a url.
 
 ```json
 "pagingScheme": {
@@ -123,9 +123,9 @@ The mandatory `request` property in the paging scheme constructs the paged query
 }
 ```
 
-The mandatory `request` property in the paging scheme constructs the paged query string.  The query string of the first API call from the above example will be: `?size=20`.  Each successive call will be structured in the pattern: `?size=20&token=891b629672384d04`.  Each paging scheme must include a `pageUntil` property which defines the point at which pagination stops.  When `noNextToken` condition is applied, `nextToken` must be included in the response object.  This string value represents the path to the expected value in the data returned from the external service.*
+The mandatory `request` property in the paging scheme constructs the paged query string. The query string of the first API call from the above example will be: `?size=20`. Each successive call will be structured in the pattern: `?size=20&token=891b629672384d04`. Each paging scheme must include a `pageUntil` property which defines the point at which pagination stops. When `noNextToken` condition is applied, `nextToken` must be included in the response object. This string value represents the path to the expected value in the data returned from the external service.\*
 
-4.  __GraphQL Connections.__  Following the GraphQL [Connections](https://graphql.org/learn/pagination/#connection-specification) specification, continue paging until `hasNextPage` is false.  Return at most `limitValue` items per page.  Supports forward, non-nested pagination.
+4.  **GraphQL Connections.** Following the GraphQL [Connections](https://graphql.org/learn/pagination/#connection-specification) specification, continue paging until `hasNextPage` is false. Return at most `limitValue` items per page. Supports forward, non-nested pagination.
 
 ```json
 "body": {
@@ -149,9 +149,9 @@ The mandatory `request` property in the paging scheme constructs the paged query
 }
 ```
 
-The paging scheme dynamically adds the `first` and `after` variables to the body of a request.  The `after` variable is defined using the `endCursor` string from the preceding response.  `pageInfo` must be included in the paging scheme response object.  This string value represents the path to the `pageInfo` object in the data returned from the external service.
+The paging scheme dynamically adds the `first` and `after` variables to the body of a request. The `after` variable is defined using the `endCursor` string from the preceding response. `pageInfo` must be included in the paging scheme response object. This string value represents the path to the `pageInfo` object in the data returned from the external service.
 
-*If values are to be found in the response header, apply the `header:` prefix.
+\*If values are to be found in the response header, apply the `header:` prefix.
 
 ## Custom Data Sources
 

doc/006-proof-types.md

@@ -12,15 +12,17 @@ Once the user selects a proof type, they may be asked for one or more criteria v
 
 Proof types retrieve data from the app's [data source](./005-data-sources.md) by name. The proof type may also provide parameter values to the data source to ensure that the right data is returned.
 
-> **IMPORTANT: Planning Your Proof Types and Fields**  
->>- Define different kinds of proof - Users, Groups, etc...
->>- Define key fields of information needed in each proof type. Make sure your API calls can return these vital elements.
->>- Define how to identify the right resource(s) - This information can be unique to each proof type and will be needed to configure `criteriafields.json` You’ll want to ask the user for these when they author the Hypersync. For example if you want to get configuration information from Azure you might need to know the tenant and subscription and resource group.
->>
-> **Tips for finding this info**:
->>- Look at console pages and dashboards. They usually contain all key information by default and are a great starting point.
->>- Look at other similar proof types in other apps.
->>- Always include proof for users and their permissions. See User Access Reviews proof for more information.
+> **IMPORTANT: Planning Your Proof Types and Fields**
+>
+> > - Define different kinds of proof - Users, Groups, etc...
+> > - Define key fields of information needed in each proof type. Make sure your API calls can return these vital elements.
+> > - Define how to identify the right resource(s) - This information can be unique to each proof type and will be needed to configure `criteriafields.json` You’ll want to ask the user for these when they author the Hypersync. For example if you want to get configuration information from Azure you might need to know the tenant and subscription and resource group.
+> >
+> > **Tips for finding this info**:
+> >
+> > - Look at console pages and dashboards. They usually contain all key information by default and are a great starting point.
+> > - Look at other similar proof types in other apps.
+> > - Always include proof for users and their permissions. See User Access Reviews proof for more information.
 
 ### Layouts
 

doc/007-criteria.md

@@ -71,7 +71,7 @@ class MyCriteriaProvider implements ICriteriaProvider{
     pages: ICriteriaPage[]
   ): Promise<ICriteriaMetadata> {
     // TODO: Generate an ICriteriaMetdata instance containing the metadata for
-    // the fields the user needs to configure, as well as defaults for the Hyperysnc
+    // the fields the user needs to configure, as well as defaults for the Hypersync
     // name, frequency of execution, and versioning behavior.
   }