@equinor/fusion-framework-cli 11.0.0-next.8 → 11.0.1

package/dist/types/lib/utils/resolve-github-annotations.d.ts

@@ -1,13 +1,44 @@
 /**
- * Interface for the expected structure of the GitHub Actions event payload.
+ * Represents the payload structure for various GitHub webhook events.
+ *
+ * This type covers common fields found in GitHub event payloads, such as push, pull request,
+ * workflow, and release events. All properties are optional to accommodate the differences
+ * between event types.
+ *
+ * @remarks only some are mapped to the GitHub API event types.
+ *
+ * @property after - The SHA of the most recent commit on the ref after the event.
+ * @property head_commit - Information about the head commit, including its SHA.
+ * @property ref - The Git ref (branch or tag) that triggered the event.
+ * @property workflow - The name of the workflow (for workflow-related events).
+ * @property action - The action performed (e.g., "opened", "closed", "created").
+ * @property repository - Information about the repository where the event occurred.
+ * @property pull_request - Details about the pull request (for pull request events).
+ * @property release - Details about the release (for release events).
+ * @property sender - Information about the user who triggered the event.
  */
-export interface GithubEventPayload {
+type GithubEventPayload = {
+    after?: string;
+    head_commit?: {
+        id?: string;
+    };
+    ref?: string;
+    workflow?: string;
+    action?: string;
+    repository?: {
+        owner?: {
+            login?: string;
+            avatar_url?: string;
+        };
+        name?: string;
+        license?: {
+            name?: string;
+        };
+        homepage?: string;
+    };
     pull_request?: {
         number?: number;
         title?: string;
-        user?: {
-            login?: string;
-        };
         head?: {
             sha?: string;
             ref?: string;
@@ -16,11 +47,6 @@ export interface GithubEventPayload {
         updated_at?: string;
         html_url?: string;
     };
-    after?: string;
-    head_commit?: {
-        id?: string;
-    };
-    ref?: string;
     release?: {
         tag_name?: string;
         name?: string;
@@ -31,9 +57,54 @@ export interface GithubEventPayload {
         published_at?: string;
         html_url?: string;
     };
+    sender?: {
+        login?: string;
+        avatar_url?: string;
+    };
+};
+/**
+ * Represents metadata and contextual information related to GitHub Actions workflows,
+ * pull requests, commits, releases, and associated actors.
+ *
+ * @property pull_request - Information about the pull request associated with the workflow run.
+ * @property pull_request.number - The pull request number.
+ * @property pull_request.title - The title of the pull request.
+ * @property pull_request.user - The user who created the pull request.
+ * @property pull_request.user.login - The login name of the pull request creator.
+ * @property pull_request.head - The head commit information of the pull request.
+ * @property pull_request.head.sha - The SHA of the head commit.
+ * @property pull_request.head.ref - The reference name of the head commit.
+ * @property pull_request.created_at - The creation timestamp of the pull request.
+ * @property pull_request.updated_at - The last update timestamp of the pull request.
+ * @property pull_request.html_url - The URL to view the pull request on GitHub.
+ * @property actor - The GitHub username of the actor who triggered the workflow.
+ * @property runId - The unique identifier of the workflow run.
+ * @property runUrl - The URL to view the workflow run on GitHub.
+ * @property repository - The full name of the repository (e.g., "owner/repo").
+ * @property after - The SHA of the commit after the workflow run.
+ * @property head_commit - Information about the head commit.
+ * @property head_commit.id - The SHA of the head commit.
+ * @property ref - The Git reference (e.g., "refs/heads/main").
+ * @property release - Information about the release associated with the workflow run.
+ * @property release.tag_name - The tag name of the release.
+ * @property release.name - The name of the release.
+ * @property release.body - The body or description of the release.
+ * @property release.draft - Indicates if the release is a draft.
+ * @property release.prerelease - Indicates if the release is a prerelease.
+ * @property release.created_at - The creation timestamp of the release.
+ * @property release.published_at - The publication timestamp of the release.
+ * @property release.html_url - The URL to view the release on GitHub.
+ * @property workflow - The name of the workflow.
+ * @property action - The name of the action being executed.
+ */
+export type GithubAnnotations = GithubEventPayload & {
     workflow?: string;
     action?: string;
-}
+    eventName: string;
+    actor?: string;
+    runId?: string;
+    runUrl?: string;
+};
 /**
  * Resolves GitHub Actions-specific annotation variables from environment variables.
  *
@@ -50,6 +121,7 @@ export interface GithubEventPayload {
  *   - GITHUB_REPOSITORY: Repository in the format owner/repo
  *   - GITHUB_SERVER_URL: Base URL of the GitHub server (defaults to https://github.com)
  *   - GITHUB_EVENT_PATH: Path to the event payload file (JSON)
+ *   - GITHUB_WORKFLOW: Name of the workflow
  *
  * Notes for maintainers:
  *   - The event payload can be large; consider truncating or parsing if only specific fields are needed.
@@ -61,5 +133,5 @@ export interface GithubEventPayload {
  *   - To add more annotations, extract additional environment variables as needed and include them in the returned object.
  *   - For custom workflows or self-hosted runners, verify that all required environment variables are available.
  */
-export declare const resolveAnnotations: () => Record<string, string>;
-export default resolveAnnotations;
+export declare const resolveGithubAnnotations: () => GithubAnnotations;
+export default resolveGithubAnnotations;

package/dist/types/lib/utils/types.d.ts

@@ -1,6 +1,62 @@
+/**
+ * Recursively makes all properties of a type optional, including nested objects and arrays.
+ *
+ * - For object types, all properties become optional and the transformation is applied deeply.
+ * - For array properties, the transformation is applied to the array's element type.
+ * - For primitive types and functions, the type is preserved as-is.
+ *
+ * This utility is useful for scenarios such as:
+ *   - Creating deeply partial configuration objects (e.g., for overrides or patch updates)
+ *   - Accepting partial user input for complex data structures
+ *   - Safely merging deeply nested objects
+ *
+ * @template T - The type to make recursively partial.
+ *
+ * @example
+ * // Simple object
+ * type Foo = { a: number; b: { c: string } };
+ * // RecursivePartial<Foo> is: { a?: number; b?: { c?: string } }
+ *
+ * // Object with array
+ * type Bar = { items: { id: string; value: number }[] };
+ * // RecursivePartial<Bar> is: { items?: Array<{ id?: string; value?: number }> }
+ *
+ * // Nested and mixed types
+ * type Baz = { x: number; y: { z: { w: string[] } } };
+ * // RecursivePartial<Baz> is: { x?: number; y?: { z?: { w?: string[] } } }
+ *
+ * // With primitives and functions
+ * type Qux = { cb: () => void; flag: boolean; nested: { n: number } };
+ * // RecursivePartial<Qux> is: { cb?: () => void; flag?: boolean; nested?: { n?: number } }
+ *
+ * @remarks
+ * - RecursivePartial preserves the original type for primitives, functions, and Date objects.
+ * - For union types, each member is transformed recursively.
+ * - TypeScript's built-in Partial<T> only makes top-level properties optional; RecursivePartial applies this deeply.
+ *
+ * @see Partial
+ * @see Value
+ */
 export type RecursivePartial<T> = {
     [P in keyof T]?: T[P] extends Array<infer U> ? Array<Value<U>> : Value<T[P]>;
 };
-type AllowedPrimitives = Function | boolean | string | number | Date;
+type AnyFunction = (...args: any[]) => unknown;
+/**
+ * Represents the set of primitive types and commonly used types allowed in the framework.
+ * Includes function types, booleans, strings, numbers, and Date objects.
+ *
+ * @remarks
+ * - `AnyFunction` should be defined elsewhere as a type representing any function signature.
+ * - Useful for constraining generic types or utility functions to a specific set of primitives.
+ */
+type AllowedPrimitives = AnyFunction | boolean | string | number | Date;
+/**
+ * Resolves to the type `T` if it extends `AllowedPrimitives`, otherwise recursively makes all properties of `T` optional.
+ *
+ * @typeParam T - The type to be evaluated.
+ * @remarks
+ * This utility type is useful for creating deeply partial versions of complex types,
+ * while preserving primitive types as-is.
+ */
 type Value<T> = T extends AllowedPrimitives ? T : RecursivePartial<T>;
 export {};

package/dist/types/version.d.ts

@@ -1 +1 @@
-export declare const version = "11.0.0-next.8";
+export declare const version = "11.0.1";

package/docs/application.md

@@ -1,71 +1,10 @@
----
-title: Developing Apps with Fusion Framework CLI
-description: >
-  In-depth guide to building, configuring, and deploying applications using the Fusion Framework CLI. Includes setup, essential commands, configuration files, CI/CD best practices, troubleshooting, and advanced tips for modern app development.
-category: cli
-related:
-  - ./auth.md
-  - ./migration-v10-to-v11.md
-tags:
-  - getting-started
-  - app-development
-  - configuration
-  - deployment
-  - ci-cd
-  - commands
-  - troubleshooting
-  - release-management
-  - automation
-  - best-practices
-  - migration
-keywords:
-  - fusion-framework-cli upload
-  - fusion-framework-cli publish
-  - fusion-framework-cli tag
-  - fusion-framework-cli config
-  - fusion-framework-cli build
-  - fusion-framework-cli pack
-  - fusion-framework-cli check
-  - fusion-framework-cli manifest
-  - fusion-framework-cli troubleshooting
-  - fusion-framework-cli deployment
-  - fusion-framework-cli ci-cd
-  - fusion app upload
-  - fusion app publish
-  - fusion app tag
-  - fusion app config
-  - fusion app build
-  - fusion app pack
-  - fusion app check
-  - fusion app manifest
-  - fusion app troubleshooting
-  - fusion app deployment
-  - fusion app ci-cd
-  - fusion cli command reference
-  - fusion cli options
-  - fusion cli arguments
----
-
-# Fusion Framework CLI: Application Development Guide
-
-> **Table of Contents**
-> - [Getting Started](#getting-started)
-> - [Prerequisites](#prerequisites)
-> - [Troubleshooting & FAQ](#troubleshooting--faq)
-> - [Configuration](#configuration)
-> - [CI/CD Best Practices](#cicd)
-> - [Command Reference](#commands)
-> - [Migration & Deprecated Commands](#aliases)
-
----
-
 The Fusion Framework CLI empowers you to rapidly build, configure, and deploy modern applications with ease. Whether you’re starting a new project or maintaining an existing app, this CLI streamlines your workflow—from local development to production deployment.
 
 This guide will help you get set up, understand the most important commands, and follow best practices for configuration and CI/CD. Let’s get started building robust, scalable apps with Fusion Framework!
 
 ## Getting Started
 
-### 1. Install the CLI
+### Install the CLI
 
 ```sh
 pnpm add -D @equinor/fusion-framework-cli
@@ -73,7 +12,7 @@ pnpm add -D @equinor/fusion-framework-cli
 npm install --save-dev @equinor/fusion-framework-cli
 ```
 
-### 2. Scaffold a New App (if supported)
+### Scaffold a New App (if supported)
 
 > **Tip:** If you have a template or starter, clone it. Otherwise, create a new directory and initialize your project as below.
 
@@ -82,7 +21,7 @@ mkdir my-fusion-app && cd my-fusion-app
 pnpm init
 ```
 
-### 3. Create Required Files
+### Create Required Files
 
 #### Minimal `package.json` Example
 
@@ -98,6 +37,18 @@ pnpm init
 }
 ```
 
+> **Build Output Configuration:**
+> The CLI uses the `main` field (or `module` field) in your `package.json` to determine where to output the built application bundle. If neither field is specified, it defaults to `./dist/bundle.js`. 
+> 
+> **Why this approach?** Using the `main`/`module` fields ensures your package works correctly when served directly or when developing portals with internal references. This follows Node.js package conventions and enables proper module resolution.
+> 
+> **Important:** The output directory cannot be the project root, the `src` directory, or the current working directory. Always specify a dedicated build directory like `dist/`, `build/`, or similar.
+>
+> **Examples:**
+> - `"main": "dist/index.js"` → outputs to `dist/index.js`
+> - `"module": "build/app.esm.js"` → outputs to `build/app.esm.js`
+> - No `main`/`module` specified → defaults to `dist/bundle.js`
+
 #### Example `app.manifest.ts`
 
 ```ts
@@ -105,8 +56,8 @@ import { defineAppManifest } from '@equinor/fusion-framework-cli/app';
 
 export default defineAppManifest(async (env, { base }) => ({
   ...base,
-  name: 'My Fusion App',
-  version: '0.0.1',
+  appKey: 'my-app',
+  displayName: 'My First Awesome Fusion App'
   // Add more manifest fields as needed
 }));
 ```
@@ -128,13 +79,22 @@ export default defineAppConfig((env, args) => ({
 }));
 ```
 
-### 4. Start the Development Server
+### Start the Development Server
 
 ```sh
 pnpm fusion-framework-cli dev
 ```
 
-### 5. Log in to Fusion Framework (if needed)
+### Log in to Fusion Framework (if needed)
+
+> [!NOTE] 
+> __All HTTP requests to Fusion services require an authorized user.__  
+> For example, before running `fusion-framework-cli app publish`, make sure you are authenticated using `fusion-framework-cli auth login`.
+
+> [!WARNING]
+> The `fusion-framework-cli auth login` command is only available in interactive environments (such as your local terminal). For CI/CD pipelines or automated deployments, you must provide a valid authentication token using the `FUSION_TOKEN` environment variable.  
+>  
+> See [Authentication](auth.md#setting-the-fusion-token-in-github) for details on setting up tokens for CI/CD.
 
 ```sh
 pnpm fusion-framework-cli auth login
@@ -144,7 +104,7 @@ pnpm fusion-framework-cli auth login
 
 ```sh
 pnpm fusion-framework-cli publish --env <environment>
-pnpm fusion-framework-cli app config --upload --env <environment>
+pnpm fusion-framework-cli app config --publish --env <environment>
 ```
 
 > **Tip:** For CI/CD and automation, set the `FUSION_TOKEN` environment variable. See [Authentication](./docs/auth.md) for details.
@@ -292,11 +252,11 @@ jobs:
       - name: Publish application
         run: pnpm exec fusion-framework-cli app upload --env ${{ matrix.env }} app-bundle.zip
       - step: Upload configuration
-        run: pnpm exec fusion-framework-cli app config --upload --env ${{ matrix.env }}
+        run: pnpm exec fusion-framework-cli app config --publish --env ${{ matrix.env }}
 ```
 
 > [!TIP]
-> see [setting-the-fusion-token-in-github](./auth.md#setting-the-fusion-token-in-github) for adding `FUSION_TOKEN` to your envirnoment
+> see [setting-the-fusion-token-in-github](auth.md#setting-the-fusion-token-in-github) for adding `FUSION_TOKEN` to your environment
 
 
 ### Example: Using Environment Variables in App Config
@@ -305,7 +265,7 @@ You can use environment variables in your app configuration to inject secrets or
 
 ```yml
 step: Upload configuration
-run: pnpm exec fusion-framework-cli app config --upload --env ${{ matrix.env }}
+run: pnpm exec fusion-framework-cli app config --publish --env ${{ matrix.env }}
 with:
   CONFIG_VALUE_FOO: ${{ VAR.ENVIRONMENT_CONFIG_VALUE }}
   CONFIG_VALUE_BAR: ${{ SECRETS.ENVIRONMENT_CONFIG_SECRET_VALUE }}
@@ -342,6 +302,7 @@ The Fusion Framework CLI provides a suite of commands to support the full applic
 - [Pack](#pack) — Bundle your app into a distributable archive.
 - [Upload](#upload) — Upload your app bundle to the Fusion app store.
 - [Tag](#tag) — Tag a published app version for release management.
+- [Manifest](#manifest) — Generate your app manifest file.
 - [Check](#check) — Verify your app's registration status.
 - [Aliases](#aliases) — Deprecated commands and their replacements.
 
@@ -383,7 +344,7 @@ Publish your application to the Fusion app store (registry) for deployment. This
 | ------------------ | --------------------------------------------------------------------------------------------------- | ----------------- |
 | `[bundle]`         | Path to the app bundle to upload. If omitted, the CLI will build and bundle your app automatically. |                   |
 | `-e`, `--env`      | Target environment for deployment (e.g., `ci`, `fqa`, `fprd`).                                      |                   |
-| `-m`, `--manifest` | Manifest file to use for bundling (e.g., `app.manifest.ts`).                                        | `app.manifest.ts` |
+| `-m`, `--manifest` | Manifest file to use for bundling (e.g., `app.manifest.ts`) (optional).                             | `app.manifest.ts` |
 | `-t`, `--tag`      | Tag to apply to the published app (`latest` \| `preview`).                                          | `latest`          |
 | `-d`, `--debug`    | Enable debug mode for verbose logging.                                                              | `false`           |
 | `--token`          | Authentication token for Fusion.                                                                    |                   |
@@ -474,6 +435,14 @@ pnpm fusion-framework-cli build
 pnpm fusion-framework-cli build app.manifest.dev.ts --debug
 ```
 
+> [!NOTE]
+> The build output location is determined by the `main` field (or `module` field) in your `package.json`. If neither field is specified, the CLI defaults to `./dist/bundle.js`. This approach ensures your package works correctly when served directly or when developing portals with internal references, following Node.js package conventions for proper module resolution. The output directory cannot be the project root, the `src` directory, or the current working directory.
+>
+> **Examples:**
+> - `"main": "dist/index.js"` → builds to `dist/index.js`
+> - `"module": "build/app.esm.js"` → builds to `build/app.esm.js`
+> - No `main`/`module` specified → defaults to `dist/bundle.js`
+
 ### Pack
 
 Build a distributable app bundle archive for deployment.
@@ -562,17 +531,42 @@ pnpm fusion-framework-cli app tag <tag> [options]
 ```sh
 pnpm fusion-framework-cli app tag latest
 pnpm fusion-framework-cli app tag preview --env prod --manifest app.manifest.prod.ts
-pnpm fusion-framework-cli app tag stable --appKey my-app --version 1.2.3
+pnpm fusion-framework-cli app tag latest --appKey my-app --version 1.2.3
 ```
 
 > [!TIP] You can roll back a release by tagging a previous build as `latest`. Simply run the tag command with the desired version to make it the active release for deployment.
 
 > [!NOTE]
 > - The `tag` command requires a published application version. You can specify the app key and version directly, or let the CLI resolve them from your manifest file.
-> - Supported tags are: `latest`, `preview`, and `stable`.
+> - Supported tags are: `latest` and `preview`.
 > - Authentication options (`--token`, `--tenantId`, `--clientId`) can be set via CLI flags or environment variables.
 > - If tagging fails, an error will be logged and the process will exit with a non-zero code.
 
+### Manifest
+
+Generate and output your application manifest for Fusion apps.
+
+| Option/Argument       | Description                                                                | Default / Example |
+| --------------------- | -------------------------------------------------------------------------- | ----------------- |
+| `[manifest]`          | Manifest build file to use (e.g., `app.manifest[.env]?.[ts,js,json]`).   | `app.manifest.ts` |
+| `-d, --debug`         | Enable debug mode for verbose logging.                                    | `false`           |
+| `-o, --output <path>` | Write manifest to the specified file (default: stdout).                   | `stdout`          |
+| `-s, --silent`        | Silent mode, suppresses output except errors.                             | `false`           |
+
+**Usage:**
+```sh
+pnpm fusion-framework-cli app manifest [manifest] [options]
+```
+
+**Examples:**
+```sh
+pnpm fusion-framework-cli app manifest
+pnpm fusion-framework-cli app manifest app.manifest.prod.ts --output ./dist/app.manifest.json
+pnpm fusion-framework-cli app manifest --debug
+```
+
+> **Tip:** By default, the manifest is printed to stdout. Use `--output` to write it to a file for use in CI/CD pipelines or for inspection.
+
 ### Check
 
 Check if a Fusion application is registered in the Fusion app store (registry).
@@ -634,11 +628,11 @@ pnpm fusion-framework-cli build-pack
 
 > [!WARNING]
 > The deprecated commands will be removed in future versions. Please update your scripts and workflows to use the new command names (`pack`, `upload`, `manifest`, `publish`) to ensure compatibility with v11 and beyond.
-> For a full migration guide, see [Migration v10 to v11](./migration-v10-to-v11.md).
+> For a full migration guide, see [Migration v10 to v11](migration-v10-to-v11.md).
 
 ---
 
 > **Need more examples?**
-> - See the [cookbooks/](../../cookbooks/) directory for real-world app examples.
-> - For migration help, see [Migration v10 to v11](./migration-v10-to-v11.md).
-> - For advanced configuration, see [Authentication](./auth.md) and [CI/CD](#cicd).
+> - See the [cookbooks directory in the GitHub repository](https://github.com/equinor/fusion-framework/tree/main/cookbooks) for real-world app examples.
+> - For migration help, see [Migration v10 to v11](migration-v10-to-v11.md).
+> - For advanced configuration, see [Authentication](auth.md) and [CI/CD](#ci-cd).

package/docs/auth.md

@@ -1,49 +1,6 @@
----
-title: Fusion Framework CLI - Authorization
-description: >
-  Comprehensive guide to authentication and authorization in the Fusion Framework CLI, covering Azure AD, MSAL, local development, CI/CD, service principals, and best practices for secure automation and integration.
-category: cli
-related:
-  - '@equinor/fusion-framework-module-msal-node/README.md'
-tags:
-  - cli
-  - fusion-framework
-  - msal
-  - azure
-  - azure-ad
-  - authentication
-  - authorization
-  - service-principal
-  - github-actions
-  - ci
-  - cd
-  - devops
-  - security
-keywords:
-  - azure ad
-  - msal
-  - access token
-  - authentication flow
-  - interactive login
-  - silent authentication
-  - token caching
-  - secure storage
-  - app registration
-  - tenant id
-  - client id
-  - scopes
-  - api permissions
-  - oidc
-  - sso
-  - cloud identity
-  - developer experience
----
-
-# Authentication with Fusion Framework CLI
-
 The Fusion Framework CLI provides secure, robust authentication for both automation and interactive development scenarios by leveraging Microsoft's MSAL (Microsoft Authentication Library) and Azure Active Directory (Azure AD). Authentication is handled through the Fusion Framework for Node.js, using the `@equinor/fusion-framework-module-msal-node` package, which is built on top of Microsoft's official `msal-node` library. This ensures standards-compliant, up-to-date authentication flows and seamless integration across Fusion Framework applications and tools.
 
-Key features include:
+## Key features
 - **Multiple authentication modes:**
   - `token_only`: Use a pre-provided token (e.g., for CI/CD and automation).
   - `silent`: Acquire tokens silently using cached or refresh tokens (background services, scripts).
@@ -75,7 +32,7 @@ When configuring authentication for the Fusion Framework CLI, you will encounter
 
 ## Local Development
 
-### Logging in with the CLI
+### Login in with the CLI
 
 For local development, you should authenticate interactively using the CLI's built-in login command. This uses the `interactive` authentication mode, which will prompt you to sign in via your browser and securely store your credentials for future CLI commands.
 
@@ -113,6 +70,22 @@ The CLI provides several authentication-related options for advanced scenarios o
 
 These options allow you to use the CLI with custom tenants, client apps, or tokens if needed, but for most development scenarios, the built-in defaults are sufficient and only the `--scope` option is commonly changed. This flexibility supports both simple and advanced authentication needs, making it easy to get started while enabling custom setups for more complex environments.
 
+### Acquiring token
+
+The `auth token` command is designed to show your access token for the current user.
+
+```sh
+fusion-framework-cli auth token
+```
+
+> [!TIP]
+> The `--silent` flag outputs only the token (no extra logging), which is useful for exporting the token as an environment variable or saving it to a file for local testing or scripting:
+> ```sh
+> export FUSION_TOKEN=$(fusion-framework-cli auth token --silent)
+> ```
+
+> [!Note] This command requires an interactive user context and MSAL Node. It is not suitable for CI/CD environments, as there is no user available in those scenarios. Use it for local development, testing, or whenever you need to preserve a Fusion token for your own scripts or tools.
+
 ## CI/CD
 
 ### Setting the Fusion Token in GitHub

package/docs/libsecret.md

@@ -1,34 +1,3 @@
----
-title: Enabling Secure Credential Storage with libsecret
-description: Instructions for installing libsecret on Linux to enable secure credential storage for your CLI.
-tags: 
-  - cli
-  - authentication
-  - keytar
-  - libsecret
-  - linux
-  - security
-  - credentials
-  - msal
-  - nodejs
-  - keychain
-keywords:
-  - secure credential storage
-  - keychain
-  - linux
-  - node.js
-  - password manager
-  - system keyring
-  - msal-node
-  - credential storage
-  - cross-platform
-  - token caching
-  - npm
-  - secrets
-  - cli authentication
-  - keytar troubleshooting
----
-
 This CLI enables secure authentication and persistent token caching by storing credentials in your system's keychain. It uses [`@azure/msal-node`](https://github.com/AzureAD/microsoft-authentication-library-for-js/tree/dev/lib/msal-node) for authentication, which relies on the [`keytar`](https://github.com/atom/node-keytar) module for secure credential storage.
 
 > **What is `libsecret`?**