@neondatabase/env 0.14.1 → 1.0.0

package/README.md

@@ -12,14 +12,13 @@ npm install @neon/env
 
 > **Requirements:** Node.js >= 20.19.
 
-## Two entry points
+## What's in it
 
-| Import | What it holds |
-| --- | --- |
-| `@neon/env` | The pure half: `fetchEnv` asks the Neon API for a branch's env, `parseEnv` reads what was already injected. Neither touches the filesystem or reads an env source. This is what an app, a build script, or a `neon.ts` policy needs. |
-| `@neon/env/runtime` | The stateful half: `fetchEnvReusingSecrets`, for tools that resolve the same branch repeatedly and must not re-mint a credential each time. It reads an env source and can mint and revoke credentials. Import it from a CLI or CI, never from an app bootstrap. |
+Everything is on `@neon/env`, and none of it has side effects: `fetchEnv` asks the Neon API for a branch's env, `parseEnv` validates what was already injected into `process.env`, `toEntries` projects a resolved env into `{ KEY: value }`. Nothing here writes a file, mutates `process.env`, or creates or destroys anything on your Neon project — so importing this package from an app, a build script, or a `neon.ts` policy can't surprise you.
+
+> **`@neon/env/runtime` was removed in 0.16.0.** It held `fetchEnvReusingSecrets`, which reads an env source and can mint and revoke branch credentials — implementation shared with the `neon` CLI, not something to hand an application. If you were importing it, the [`neon` CLI](../cli) (`neon env pull`, `neon dev`) does the same job; if you need to do it yourself, [The branch credential](#the-branch-credential) says what the hard part actually is.
 
-The split mirrors [`@neon/config`](../config) vs [`@neon/config-runtime`](../config-runtime), for the same reason: side effects should be something you opt into by import path. Contributing to either half? See [`CONTRIBUTING.md`](./CONTRIBUTING.md).
+Contributing? See [`CONTRIBUTING.md`](./CONTRIBUTING.md).
 
 ## Functions
 
@@ -55,7 +54,6 @@ Both return the same namespaced `NeonEnv` shape: `postgres` is always present; `
 | Function | Description |
 | --- | --- |
 | `fetchEnv(config, { projectId, branch, ... })` | Async. Calls the Neon API for the given project + branch and returns live connection strings (and Auth/Data API values when enabled). `projectId` and `branch` are required; `branch` accepts a branch **name** (e.g. `main`) or a `br-…` id. (The legacy id-only `branchId` option still works.) Pass `keys` to fetch only some vars — see [Fetching a subset](#fetching-a-subset). Reads nothing from `process.env` or disk. |
-| `fetchEnvReusingSecrets(config, { projectId, branch, env })` | Async, from **`@neon/env/runtime`**. `fetchEnv` plus reuse of one-time secrets you already hold: verifies them against the branch, keeps what's valid, mints and revokes only when it must. Returns `{ vars, credential }`. Use this rather than `fetchEnv` anywhere the same branch is resolved repeatedly — see [The branch credential](#the-branch-credential). |
 | `parseEnv(config)` / `parseEnv(config, slug)` / `parseEnv(config, keys)` | Sync. Reads/validates the Neon env vars already present in `process.env` against the static policy toggles. With a function `slug`, also returns a typed `function` namespace of that function's declared env keys. With a `keys` array (e.g. `["DATABASE_URL"]`), only those vars are required and returned, as a narrowed namespaced shape — the keys are typesafe against the policy. Throws `PlatformError(EnvNotInjected)` listing missing vars when the env isn't populated. |
 | `toEntries(env)` | Project a resolved `NeonEnv` into `{ KEY: value }` pairs for cross-process transport (named after the web `.entries()` convention; returns a `Record`). |
 
@@ -135,27 +133,11 @@ These are the OS-level vars `fetchEnv` / `parseEnv` read and `toEntries` (so `ne
 
 Object storage and the AI Gateway are backed by one branch credential, and the Neon API returns its secrets (`s3_secret_access_key`, `api_token`) **once**, at mint time — they aren't stored server-side, and the list endpoint returns metadata only. So there is nothing to *fetch*: `fetchEnv` mints. Call it on every `neon dev` start and you leave a live credential behind each time.
 
-`fetchEnvReusingSecrets`, from the **`@neon/env/runtime`** entry point, is the wrapper that avoids that. It checks what you already hold, keeps what is still valid, and asks `fetchEnv` for only the rest:
-
-```ts
-import { fetchEnvReusingSecrets } from "@neon/env/runtime";
-
-const { vars, credential } = await fetchEnvReusingSecrets(config, {
-    projectId,
-    branch: "main",
-    env: { ...process.env, ...readEnvFile(".env") },
-});
-
-// vars: { DATABASE_URL: "…", AWS_ACCESS_KEY_ID: "…", … } — ready to write or inject
-if (credential.issued) {
-    console.log(`new values for ${credential.keys.join(", ")}`);
-    // credential.revoked holds the token ids it superseded
-}
-```
+Handling that is the caller's problem, and it is not just "cache the secret": a persisted secret is only reusable if it still names a live credential on that branch — unrevoked, unexpired, and carrying every scope the policy needs. A presence check cannot tell a real secret from a `.env.example` placeholder.
 
-The check is a real verification, not a presence test. A persisted secret is kept only when it names a credential that still exists on the branch, isn't revoked or expired, and carries every scope the policy needs. A `.env.example` placeholder, a credential revoked in the console, one copied from another branch, or one predating a newly-enabled feature all fail that check and get replaced — and the credential being replaced is revoked, so a branch doesn't accumulate one per call.
+No local bookkeeping is needed to do it, because the secrets carry their own credential id: `AWS_ACCESS_KEY_ID` **is** the credential's token id, and the AI Gateway token is minted as `nt_live_<tokenIdShort>_<secret>`. So the `.env` you are about to rewrite already records which credential issued it.
 
-No local bookkeeping backs this: `AWS_ACCESS_KEY_ID` **is** the credential's token id, and the AI Gateway token is minted as `nt_live_<tokenIdShort>_<secret>`, so the persisted secrets already name the credential that issued them.
+The [`neon` CLI](../cli) does all of this — `neon env pull` and `neon dev` reuse a branch credential rather than issuing one per run. If you are calling `fetchEnv` on a loop yourself, `credentialScopesSatisfied` and `deriveCredentialScopes` from `@neon/config/v1`, plus `listCredentials` / `createCredential` / `revokeCredential` on a `NeonApi`, are the pieces you need.
 
 ### Fetching a subset
 

package/dist/_shared/auth_selection.d.ts

@@ -0,0 +1,95 @@
+//#region src/_shared/auth_selection.d.ts
+/**
+ * # Which credential an invocation authenticates with
+ *
+ * Four inputs can each answer "who am I": the `--api-key` flag, `NEON_API_KEY`, the
+ * `--profile` flag, and `NEON_PROFILE`. This module decides between them, and it is pure so
+ * the decision can be tested without a filesystem, a network, or a config directory.
+ *
+ * ## The rule
+ *
+ * **An explicit flag beats an ambient environment variable.** That single rule fixes the bug
+ * this module exists for: before it, any API key — including one merely exported into the
+ * shell — silently voided `--profile`, so `neon --profile work …` would quietly run as
+ * whoever `NEON_API_KEY` belonged to and say nothing about it.
+ *
+ * | Given | What runs |
+ * | --- | --- |
+ * | `--api-key` and `--profile` | neither: contradictory explicit flags, so this throws |
+ * | `--api-key` and `NEON_PROFILE` | the flag's key |
+ * | `--profile` and `NEON_API_KEY` | the profile |
+ * | `NEON_API_KEY` and `NEON_PROFILE` | the key, and the ignored profile is named in a warning |
+ * | `--profile` or `NEON_PROFILE` alone | that profile |
+ * | nothing | `DEFAULT` |
+ *
+ * Two explicit flags throw rather than picking a winner. They express different intents —
+ * `--api-key` supplies a credential, `--profile` selects a stored one — so there is no
+ * reading of the command that makes both true, and guessing is how the original bug behaved.
+ *
+ * When both are merely ambient, the key wins. That keeps CI exactly as it was: a pipeline
+ * that injects `NEON_API_KEY` must not change behaviour because a `NEON_PROFILE` leaked into
+ * the environment. It warns instead of staying silent, because a disregarded account
+ * selection is precisely what nobody noticed last time.
+ *
+ * `auth` and the `profile` subcommands do not use any of this. They read the same flags with
+ * different meanings — `neon auth --profile work` names where to *write* a credential, and
+ * `neon profile create work --api-key …` names one to *store* — so their callers skip
+ * selection entirely rather than passing exemptions down here.
+ */
+type CredentialSelection = /** `--api-key`. Used as given; no profile is consulted and no stored file is touched. */
+{
+  source: "explicit-api-key";
+  apiKey: string;
+}
+/** `NEON_API_KEY`, with the profile it displaced when there was one. */ | {
+  source: "ambient-api-key";
+  apiKey: string;
+  ignoredProfile?: string;
+}
+/** A profile, whose file decides whether that means an API key or OAuth. */ | {
+  source: "profile";
+  profile: string;
+  explicit: boolean;
+};
+type SelectionInput = {
+  /** The `--api-key` flag, before any environment fallback has been folded into it. */
+  apiKeyFlag?: string;
+  /** The `--profile` flag. */
+  profileFlag?: string;
+  /** `NEON_API_KEY`. */
+  apiKeyEnv?: string;
+  /** `NEON_PROFILE`. */
+  profileEnv?: string;
+};
+/**
+ * What the four credential inputs were for this invocation, captured by
+ * `resolveApiKeyFromEnv` — which is the one place that reads the environment.
+ *
+ * Two reasons this is module state rather than fields on the parsed arguments, the same two
+ * that put `auth_context` here: an extra key on `args` is rejected by every command calling
+ * `.strict()`, and a hidden option to carry it would be a second undocumented way to pass a
+ * credential. One process is one invocation, so there is nothing to get out of step.
+ *
+ * Capturing the environment here rather than reading it inside {@link selectCredential} keeps
+ * the selection a function of its arguments. That is not tidiness: `ensureAuth` is called
+ * directly by tests, and reading `process.env` down in the decision made those tests depend on
+ * whether the developer running them happened to have `NEON_API_KEY` exported.
+ */
+type CredentialInputs = {
+  apiKeyFlag: string;
+  apiKeyEnv: string;
+  profileEnv: string;
+};
+declare const recordCredentialInputs: (recorded: CredentialInputs) => void;
+declare const credentialInputs: () => CredentialInputs;
+declare const selectCredential: ({
+  apiKeyFlag,
+  profileFlag,
+  apiKeyEnv,
+  profileEnv
+}: SelectionInput) => CredentialSelection;
+/** The warning for an ambient key that displaced an ambient profile, or `null`. */
+declare const displacedProfileWarning: (selection: CredentialSelection) => string | null;
+//#endregion
+export { CredentialInputs, CredentialSelection, SelectionInput, credentialInputs, displacedProfileWarning, recordCredentialInputs, selectCredential };
+//# sourceMappingURL=auth_selection.d.ts.map

package/dist/_shared/auth_selection.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"auth_selection.d.ts","names":[],"sources":["../../src/_shared/auth_selection.ts"],"mappings":";;AAwCA;AAQA;AAyBA;AAcA;AAIA;AAEA;AAuCC;AAvCgC;AAAA;AAAA;AAAA;AAK9B;AAAiB;AAkCnB;AAGD;;;;;;;;;;;;;;;;;;;;;;KA/FY,mBAAA;;;;;;;;;;;;;;;KAQA,cAAA;;;;;;;;;;;;;;;;;;;;;;;;KAyBA,gBAAA;;;;;cAcC,mCAAoC;cAIpC,wBAAuB;cAEvB;;;;;GAKV,mBAAiB;;cAqCP,qCACD"}

package/dist/_shared/auth_selection.js

@@ -37,6 +37,15 @@ import "./profiles.js";
 * `neon profile create work --api-key …` names one to *store* — so their callers skip
 * selection entirely rather than passing exemptions down here.
 */
+let inputs = {
+	apiKeyFlag: "",
+	apiKeyEnv: "",
+	profileEnv: ""
+};
+const recordCredentialInputs = (recorded) => {
+	inputs = recorded;
+};
+const credentialInputs = () => inputs;
 const selectCredential = ({ apiKeyFlag, profileFlag, apiKeyEnv, profileEnv }) => {
 	const flagKey = nonEmpty(apiKeyFlag);
 	const flagProfile = nonEmpty(profileFlag);
@@ -71,6 +80,6 @@ function nonEmpty(value) {
 	return trimmed === "" ? void 0 : trimmed;
 }
 //#endregion
-export { displacedProfileWarning, selectCredential };
+export { credentialInputs, displacedProfileWarning, recordCredentialInputs, selectCredential };
 
 //# sourceMappingURL=auth_selection.js.map

package/dist/_shared/auth_selection.js.map

@@ -1 +1 @@
-{"version":3,"file":"auth_selection.js","names":[],"sources":["../../src/_shared/auth_selection.ts"],"sourcesContent":["/**\n * # Which credential an invocation authenticates with\n *\n * Four inputs can each answer \"who am I\": the `--api-key` flag, `NEON_API_KEY`, the\n * `--profile` flag, and `NEON_PROFILE`. This module decides between them, and it is pure so\n * the decision can be tested without a filesystem, a network, or a config directory.\n *\n * ## The rule\n *\n * **An explicit flag beats an ambient environment variable.** That single rule fixes the bug\n * this module exists for: before it, any API key — including one merely exported into the\n * shell — silently voided `--profile`, so `neon --profile work …` would quietly run as\n * whoever `NEON_API_KEY` belonged to and say nothing about it.\n *\n * | Given | What runs |\n * | --- | --- |\n * | `--api-key` and `--profile` | neither: contradictory explicit flags, so this throws |\n * | `--api-key` and `NEON_PROFILE` | the flag's key |\n * | `--profile` and `NEON_API_KEY` | the profile |\n * | `NEON_API_KEY` and `NEON_PROFILE` | the key, and the ignored profile is named in a warning |\n * | `--profile` or `NEON_PROFILE` alone | that profile |\n * | nothing | `DEFAULT` |\n *\n * Two explicit flags throw rather than picking a winner. They express different intents —\n * `--api-key` supplies a credential, `--profile` selects a stored one — so there is no\n * reading of the command that makes both true, and guessing is how the original bug behaved.\n *\n * When both are merely ambient, the key wins. That keeps CI exactly as it was: a pipeline\n * that injects `NEON_API_KEY` must not change behaviour because a `NEON_PROFILE` leaked into\n * the environment. It warns instead of staying silent, because a disregarded account\n * selection is precisely what nobody noticed last time.\n *\n * `auth` and the `profile` subcommands do not use any of this. They read the same flags with\n * different meanings — `neon auth --profile work` names where to *write* a credential, and\n * `neon profile create work --api-key …` names one to *store* — so their callers skip\n * selection entirely rather than passing exemptions down here.\n */\n\nimport { DEFAULT_PROFILE } from \"./profiles.js\";\n\nexport type CredentialSelection =\n\t/** `--api-key`. Used as given; no profile is consulted and no stored file is touched. */\n\t| { source: \"explicit-api-key\"; apiKey: string }\n\t/** `NEON_API_KEY`, with the profile it displaced when there was one. */\n\t| { source: \"ambient-api-key\"; apiKey: string; ignoredProfile?: string }\n\t/** A profile, whose file decides whether that means an API key or OAuth. */\n\t| { source: \"profile\"; profile: string; explicit: boolean };\n\nexport type SelectionInput = {\n\t/** The `--api-key` flag, before any environment fallback has been folded into it. */\n\tapiKeyFlag?: string;\n\t/** The `--profile` flag. */\n\tprofileFlag?: string;\n\t/** `NEON_API_KEY`. */\n\tapiKeyEnv?: string;\n\t/** `NEON_PROFILE`. */\n\tprofileEnv?: string;\n};\n\n/**\n * What the four credential inputs were for this invocation, captured by\n * `resolveApiKeyFromEnv` — which is the one place that reads the environment.\n *\n * Two reasons this is module state rather than fields on the parsed arguments, the same two\n * that put `auth_context` here: an extra key on `args` is rejected by every command calling\n * `.strict()`, and a hidden option to carry it would be a second undocumented way to pass a\n * credential. One process is one invocation, so there is nothing to get out of step.\n *\n * Capturing the environment here rather than reading it inside {@link selectCredential} keeps\n * the selection a function of its arguments. That is not tidiness: `ensureAuth` is called\n * directly by tests, and reading `process.env` down in the decision made those tests depend on\n * whether the developer running them happened to have `NEON_API_KEY` exported.\n */\nexport type CredentialInputs = {\n\tapiKeyFlag: string;\n\tapiKeyEnv: string;\n\tprofileEnv: string;\n};\n\nconst NO_INPUTS: CredentialInputs = {\n\tapiKeyFlag: \"\",\n\tapiKeyEnv: \"\",\n\tprofileEnv: \"\",\n};\n\nlet inputs: CredentialInputs = NO_INPUTS;\n\nexport const recordCredentialInputs = (recorded: CredentialInputs): void => {\n\tinputs = recorded;\n};\n\nexport const credentialInputs = (): CredentialInputs => inputs;\n\nexport const selectCredential = ({\n\tapiKeyFlag,\n\tprofileFlag,\n\tapiKeyEnv,\n\tprofileEnv,\n}: SelectionInput): CredentialSelection => {\n\tconst flagKey = nonEmpty(apiKeyFlag);\n\tconst flagProfile = nonEmpty(profileFlag);\n\n\tif (flagKey !== undefined && flagProfile !== undefined) {\n\t\tthrow new Error(\n\t\t\t\"Pass either --api-key or --profile, not both. --api-key supplies a credential directly; --profile selects a stored one.\",\n\t\t);\n\t}\n\n\tif (flagKey !== undefined) {\n\t\treturn { source: \"explicit-api-key\", apiKey: flagKey };\n\t}\n\n\tif (flagProfile !== undefined) {\n\t\treturn { source: \"profile\", profile: flagProfile, explicit: true };\n\t}\n\n\tconst envKey = nonEmpty(apiKeyEnv);\n\tconst envProfile = nonEmpty(profileEnv);\n\n\tif (envKey !== undefined) {\n\t\treturn {\n\t\t\tsource: \"ambient-api-key\",\n\t\t\tapiKey: envKey,\n\t\t\t...(envProfile !== undefined ? { ignoredProfile: envProfile } : {}),\n\t\t};\n\t}\n\n\treturn {\n\t\tsource: \"profile\",\n\t\tprofile: envProfile ?? DEFAULT_PROFILE,\n\t\texplicit: envProfile !== undefined,\n\t};\n};\n\n/** The warning for an ambient key that displaced an ambient profile, or `null`. */\nexport const displacedProfileWarning = (\n\tselection: CredentialSelection,\n): string | null =>\n\tselection.source === \"ambient-api-key\" &&\n\tselection.ignoredProfile !== undefined\n\t\t? `NEON_API_KEY is set, so profile \"${selection.ignoredProfile}\" from NEON_PROFILE was ignored. Pass --profile ${selection.ignoredProfile} to use it instead.`\n\t\t: null;\n\nfunction nonEmpty(value: string | undefined): string | undefined {\n\tif (typeof value !== \"string\") return undefined;\n\tconst trimmed = value.trim();\n\treturn trimmed === \"\" ? undefined : trimmed;\n}\n"],"mappings":";;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;AA6FA,MAAa,oBAAoB,EAChC,YACA,aACA,WACA,iBAC0C;CAC1C,MAAM,UAAU,SAAS,UAAU;CACnC,MAAM,cAAc,SAAS,WAAW;CAExC,IAAI,YAAY,KAAA,KAAa,gBAAgB,KAAA,GAC5C,MAAM,IAAI,MACT,yHACD;CAGD,IAAI,YAAY,KAAA,GACf,OAAO;EAAE,QAAQ;EAAoB,QAAQ;CAAQ;CAGtD,IAAI,gBAAgB,KAAA,GACnB,OAAO;EAAE,QAAQ;EAAW,SAAS;EAAa,UAAU;CAAK;CAGlE,MAAM,SAAS,SAAS,SAAS;CACjC,MAAM,aAAa,SAAS,UAAU;CAEtC,IAAI,WAAW,KAAA,GACd,OAAO;EACN,QAAQ;EACR,QAAQ;EACR,GAAI,eAAe,KAAA,IAAY,EAAE,gBAAgB,WAAW,IAAI,CAAC;CAClE;CAGD,OAAO;EACN,QAAQ;EACR,SAAS,cAAA;EACT,UAAU,eAAe,KAAA;CAC1B;AACD;;AAGA,MAAa,2BACZ,cAEA,UAAU,WAAW,qBACrB,UAAU,mBAAmB,KAAA,IAC1B,oCAAoC,UAAU,eAAe,kDAAkD,UAAU,eAAe,uBACxI;AAEJ,SAAS,SAAS,OAA+C;CAChE,IAAI,OAAO,UAAU,UAAU,OAAO,KAAA;CACtC,MAAM,UAAU,MAAM,KAAK;CAC3B,OAAO,YAAY,KAAK,KAAA,IAAY;AACrC"}
+{"version":3,"file":"auth_selection.js","names":[],"sources":["../../src/_shared/auth_selection.ts"],"sourcesContent":["/**\n * # Which credential an invocation authenticates with\n *\n * Four inputs can each answer \"who am I\": the `--api-key` flag, `NEON_API_KEY`, the\n * `--profile` flag, and `NEON_PROFILE`. This module decides between them, and it is pure so\n * the decision can be tested without a filesystem, a network, or a config directory.\n *\n * ## The rule\n *\n * **An explicit flag beats an ambient environment variable.** That single rule fixes the bug\n * this module exists for: before it, any API key — including one merely exported into the\n * shell — silently voided `--profile`, so `neon --profile work …` would quietly run as\n * whoever `NEON_API_KEY` belonged to and say nothing about it.\n *\n * | Given | What runs |\n * | --- | --- |\n * | `--api-key` and `--profile` | neither: contradictory explicit flags, so this throws |\n * | `--api-key` and `NEON_PROFILE` | the flag's key |\n * | `--profile` and `NEON_API_KEY` | the profile |\n * | `NEON_API_KEY` and `NEON_PROFILE` | the key, and the ignored profile is named in a warning |\n * | `--profile` or `NEON_PROFILE` alone | that profile |\n * | nothing | `DEFAULT` |\n *\n * Two explicit flags throw rather than picking a winner. They express different intents —\n * `--api-key` supplies a credential, `--profile` selects a stored one — so there is no\n * reading of the command that makes both true, and guessing is how the original bug behaved.\n *\n * When both are merely ambient, the key wins. That keeps CI exactly as it was: a pipeline\n * that injects `NEON_API_KEY` must not change behaviour because a `NEON_PROFILE` leaked into\n * the environment. It warns instead of staying silent, because a disregarded account\n * selection is precisely what nobody noticed last time.\n *\n * `auth` and the `profile` subcommands do not use any of this. They read the same flags with\n * different meanings — `neon auth --profile work` names where to *write* a credential, and\n * `neon profile create work --api-key …` names one to *store* — so their callers skip\n * selection entirely rather than passing exemptions down here.\n */\n\nimport { DEFAULT_PROFILE } from \"./profiles.js\";\n\nexport type CredentialSelection =\n\t/** `--api-key`. Used as given; no profile is consulted and no stored file is touched. */\n\t| { source: \"explicit-api-key\"; apiKey: string }\n\t/** `NEON_API_KEY`, with the profile it displaced when there was one. */\n\t| { source: \"ambient-api-key\"; apiKey: string; ignoredProfile?: string }\n\t/** A profile, whose file decides whether that means an API key or OAuth. */\n\t| { source: \"profile\"; profile: string; explicit: boolean };\n\nexport type SelectionInput = {\n\t/** The `--api-key` flag, before any environment fallback has been folded into it. */\n\tapiKeyFlag?: string;\n\t/** The `--profile` flag. */\n\tprofileFlag?: string;\n\t/** `NEON_API_KEY`. */\n\tapiKeyEnv?: string;\n\t/** `NEON_PROFILE`. */\n\tprofileEnv?: string;\n};\n\n/**\n * What the four credential inputs were for this invocation, captured by\n * `resolveApiKeyFromEnv` — which is the one place that reads the environment.\n *\n * Two reasons this is module state rather than fields on the parsed arguments, the same two\n * that put `auth_context` here: an extra key on `args` is rejected by every command calling\n * `.strict()`, and a hidden option to carry it would be a second undocumented way to pass a\n * credential. One process is one invocation, so there is nothing to get out of step.\n *\n * Capturing the environment here rather than reading it inside {@link selectCredential} keeps\n * the selection a function of its arguments. That is not tidiness: `ensureAuth` is called\n * directly by tests, and reading `process.env` down in the decision made those tests depend on\n * whether the developer running them happened to have `NEON_API_KEY` exported.\n */\nexport type CredentialInputs = {\n\tapiKeyFlag: string;\n\tapiKeyEnv: string;\n\tprofileEnv: string;\n};\n\nconst NO_INPUTS: CredentialInputs = {\n\tapiKeyFlag: \"\",\n\tapiKeyEnv: \"\",\n\tprofileEnv: \"\",\n};\n\nlet inputs: CredentialInputs = NO_INPUTS;\n\nexport const recordCredentialInputs = (recorded: CredentialInputs): void => {\n\tinputs = recorded;\n};\n\nexport const credentialInputs = (): CredentialInputs => inputs;\n\nexport const selectCredential = ({\n\tapiKeyFlag,\n\tprofileFlag,\n\tapiKeyEnv,\n\tprofileEnv,\n}: SelectionInput): CredentialSelection => {\n\tconst flagKey = nonEmpty(apiKeyFlag);\n\tconst flagProfile = nonEmpty(profileFlag);\n\n\tif (flagKey !== undefined && flagProfile !== undefined) {\n\t\tthrow new Error(\n\t\t\t\"Pass either --api-key or --profile, not both. --api-key supplies a credential directly; --profile selects a stored one.\",\n\t\t);\n\t}\n\n\tif (flagKey !== undefined) {\n\t\treturn { source: \"explicit-api-key\", apiKey: flagKey };\n\t}\n\n\tif (flagProfile !== undefined) {\n\t\treturn { source: \"profile\", profile: flagProfile, explicit: true };\n\t}\n\n\tconst envKey = nonEmpty(apiKeyEnv);\n\tconst envProfile = nonEmpty(profileEnv);\n\n\tif (envKey !== undefined) {\n\t\treturn {\n\t\t\tsource: \"ambient-api-key\",\n\t\t\tapiKey: envKey,\n\t\t\t...(envProfile !== undefined ? { ignoredProfile: envProfile } : {}),\n\t\t};\n\t}\n\n\treturn {\n\t\tsource: \"profile\",\n\t\tprofile: envProfile ?? DEFAULT_PROFILE,\n\t\texplicit: envProfile !== undefined,\n\t};\n};\n\n/** The warning for an ambient key that displaced an ambient profile, or `null`. */\nexport const displacedProfileWarning = (\n\tselection: CredentialSelection,\n): string | null =>\n\tselection.source === \"ambient-api-key\" &&\n\tselection.ignoredProfile !== undefined\n\t\t? `NEON_API_KEY is set, so profile \"${selection.ignoredProfile}\" from NEON_PROFILE was ignored. Pass --profile ${selection.ignoredProfile} to use it instead.`\n\t\t: null;\n\nfunction nonEmpty(value: string | undefined): string | undefined {\n\tif (typeof value !== \"string\") return undefined;\n\tconst trimmed = value.trim();\n\treturn trimmed === \"\" ? undefined : trimmed;\n}\n"],"mappings":";;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;AAqFA,IAAI,SAA2B;CAL9B,YAAY;CACZ,WAAW;CACX,YAAY;AAG0B;AAEvC,MAAa,0BAA0B,aAAqC;CAC3E,SAAS;AACV;AAEA,MAAa,yBAA2C;AAExD,MAAa,oBAAoB,EAChC,YACA,aACA,WACA,iBAC0C;CAC1C,MAAM,UAAU,SAAS,UAAU;CACnC,MAAM,cAAc,SAAS,WAAW;CAExC,IAAI,YAAY,KAAA,KAAa,gBAAgB,KAAA,GAC5C,MAAM,IAAI,MACT,yHACD;CAGD,IAAI,YAAY,KAAA,GACf,OAAO;EAAE,QAAQ;EAAoB,QAAQ;CAAQ;CAGtD,IAAI,gBAAgB,KAAA,GACnB,OAAO;EAAE,QAAQ;EAAW,SAAS;EAAa,UAAU;CAAK;CAGlE,MAAM,SAAS,SAAS,SAAS;CACjC,MAAM,aAAa,SAAS,UAAU;CAEtC,IAAI,WAAW,KAAA,GACd,OAAO;EACN,QAAQ;EACR,QAAQ;EACR,GAAI,eAAe,KAAA,IAAY,EAAE,gBAAgB,WAAW,IAAI,CAAC;CAClE;CAGD,OAAO;EACN,QAAQ;EACR,SAAS,cAAA;EACT,UAAU,eAAe,KAAA;CAC1B;AACD;;AAGA,MAAa,2BACZ,cAEA,UAAU,WAAW,qBACrB,UAAU,mBAAmB,KAAA,IAC1B,oCAAoC,UAAU,eAAe,kDAAkD,UAAU,eAAe,uBACxI;AAEJ,SAAS,SAAS,OAA+C;CAChE,IAAI,OAAO,UAAU,UAAU,OAAO,KAAA;CACtC,MAAM,UAAU,MAAM,KAAK;CAC3B,OAAO,YAAY,KAAK,KAAA,IAAY;AACrC"}

package/dist/_shared/credentials.d.ts

@@ -0,0 +1,186 @@
+//#region src/_shared/credentials.d.ts
+/**
+ * # Stored credentials — one file per account, two kinds
+ *
+ * A profile points at exactly one credentials file (see `./profiles.ts`), and that file says
+ * what kind of credential it holds. Adding API-key support this way rather than adding a
+ * second pointer to `profiles.json` keeps a profile what it already was — one name, one path
+ * — and means `profiles.json` needs no schema change at all.
+ *
+ * ```json
+ * // oauth: every file written before this existed. An absent `type` means this.
+ * { "access_token": "…", "refresh_token": "…", "expires_at": 1786…, "user_id": "…" }
+ *
+ * // api_key, stored by `neon profile create --api-key`
+ * { "type": "api_key", "api_key": "napi_…", "user_id": "…" }
+ *
+ * // api_key minted by `--mint --org-id`, which records the scope it was issued at
+ * { "type": "api_key", "api_key": "napi_…", "key_id": 123, "org_id": "org-…" }
+ * ```
+ *
+ * ## One profile, one kind
+ *
+ * A credentials file holds an API key or an OAuth session, never both, and `type` states
+ * which. An earlier draft let the two coexist — the idea being that a key could keep the
+ * session it was minted from and so rotate without a browser. It did not survive review, for
+ * two reasons that are worth recording so nobody rebuilds it:
+ *
+ * 1. **It never worked.** The resolver returned the key without testing it, so a revoked key
+ *    failed to mint and never fell back to the session sitting beside it.
+ * 2. **It could mix accounts.** Nothing compared the identity of the credential being written
+ *    with the one already there, so a profile could hold one account's session and another's
+ *    key, told apart only by a single string. Flip or lose `type` and the profile silently
+ *    becomes a different person.
+ *
+ * Recovery from a dead key is therefore one browser login — `neon profile create <name>
+ * --mint --force` — which is what the retained session was supposed to save and never did.
+ *
+ * ## Older releases
+ *
+ * A CLI predating this reads the pointer, finds no `type` it understands, ignores it, and
+ * looks for `access_token`. An `api_key` profile has none, so an older release falls through
+ * to its browser login rather than crashing. That it does not crash is why `credentials`
+ * stays a required pointer: an entry without one makes 2.41 and 2.42 throw
+ * `ERR_INVALID_ARG_TYPE` from `resolveEntryPath`.
+ */
+declare const OAUTH = "oauth";
+declare const API_KEY = "api_key";
+type CredentialKind = typeof OAUTH | typeof API_KEY;
+/**
+ * The on-disk shape. Every field is optional because the two kinds overlap and because an
+ * OAuth token endpoint response carries more than we name here — the index signature keeps
+ * those extra fields on a round-trip rather than dropping them.
+ */
+type StoredCredentials = {
+  type?: string;
+  api_key?: string;
+  key_id?: number;
+  /** Set when the key was minted for an organization rather than the account. */
+  org_id?: string;
+  /** Set when the key was narrowed to a single project. Implies `org_id`. */
+  project_id?: string;
+  user_id?: string;
+  access_token?: string;
+  refresh_token?: string;
+  expires_at?: number;
+  [key: string]: unknown;
+};
+/**
+ * Where a credential lives, and which profile points at it.
+ *
+ * Both halves are needed to report a broken file: the path says which file to open, and the
+ * profile is what every recovery command takes as its argument. Carrying only the path is what
+ * produced errors telling the user to run `neon profile create <name> --force` with the
+ * placeholder intact — a command an agent will run verbatim and be told `Invalid profile name
+ * "<name>"`.
+ */
+type CredentialLocation = {
+  path: string;
+  profile: string;
+};
+/**
+ * Which credential in this file authenticates, by declaration alone.
+ *
+ * An unrecognised `type` throws rather than falling back to `oauth`. A file we cannot
+ * interpret is a misconfiguration the user has to see: treating it as OAuth would send them
+ * to a browser login that silently replaces a credential they meant to keep, and treating it
+ * as an API key would authenticate with whatever `api_key` happened to be there.
+ *
+ * This deliberately does not check that an `api_key` file has a key — `neon profile list`
+ * needs the kind of a file it is not about to authenticate with, and must be able to report a
+ * broken one rather than throwing halfway through a table.
+ */
+declare const credentialKind: (credentials: StoredCredentials, at: CredentialLocation) => CredentialKind;
+/** A credentials file resolved far enough to authenticate with. */
+type InterpretedCredentials = {
+  kind: typeof API_KEY;
+  apiKey: string;
+} | {
+  kind: typeof OAUTH;
+};
+/**
+ * Resolve what to authenticate with, validating that the declared kind is actually usable.
+ *
+ * An `api_key` file with no key is a hard error rather than a fall-through to OAuth: the user
+ * asked for a key, and quietly opening a browser instead would replace the credential they
+ * were trying to fix.
+ */
+declare const interpretCredentials: (credentials: StoredCredentials, at: CredentialLocation) => InterpretedCredentials;
+/**
+ * Read a credentials file, or `null` when there is nothing usable there.
+ *
+ * Missing and unparseable both return `null`, because both are recoverable by authenticating
+ * again and the callers already treat "no credentials" as "log in". A file that parses but
+ * contradicts itself is different — {@link credentialKind} throws for that, since re-running
+ * `auth` would paper over a mistake rather than fix it.
+ */
+type CredentialsRead = {
+  kind: "ok";
+  credentials: StoredCredentials;
+} | {
+  kind: "absent";
+}
+/** The file is there but cannot be understood. `reason` is safe to print. */ | {
+  kind: "unusable";
+  reason: string;
+};
+/**
+ * Read and classify a credentials file, without deciding what to do about it.
+ *
+ * A permission or I/O error still throws: there may be a perfectly good credential here that
+ * we cannot see, and treating that as absent would send the user to a browser login that
+ * overwrites it.
+ */
+declare const inspectCredentials: (path: string) => CredentialsRead;
+/**
+ * The credential at `path`, or `null` when the file is not there.
+ *
+ * A damaged file is an error, not an absence. Treating it as absent — which is what this used to
+ * do — meant any read-only command could repair it by starting a browser sign-in and overwriting
+ * it, **possibly as a different account**, with the user never having asked for a repair and no
+ * way back to whatever was in the file. Failing here costs one deliberate command; the message
+ * names it.
+ *
+ * `profile list` and telemetry use {@link inspectCredentials} instead, because describing a
+ * broken credential is not the same as using one.
+ */
+declare const readCredentials: (at: CredentialLocation) => StoredCredentials | null;
+declare const writeCredentials: (path: string, credentials: StoredCredentials) => void;
+/** The scope a minted key was issued at. Absent org means an account key. */
+type KeyScope = {
+  orgId?: string;
+  projectId?: string;
+};
+/**
+ * Build an `api_key` credentials object. Nothing from a previous credential is carried over.
+ *
+ * The scope is stored because it is not recoverable from the secret: `rotate-key` has to mint
+ * the replacement on the same endpoint, and an org or project key minted as an account key
+ * would silently widen what the profile reaches.
+ */
+declare const apiKeyCredentials: ({
+  apiKey,
+  keyId,
+  userId,
+  scope
+}: {
+  apiKey: string;
+  keyId?: number;
+  userId?: string;
+  scope?: KeyScope;
+}) => StoredCredentials;
+/** The scope recorded on a stored credential. */
+declare const scopeOf: (credentials: StoredCredentials) => KeyScope;
+/** How to describe a scope in output. */
+declare const describeScope: (scope: KeyScope) => string;
+/**
+ * Whether a stored credential is the same secret as the one about to replace it.
+ *
+ * Re-storing the key a profile already holds is a no-op, not a replacement — and retiring it
+ * would revoke the credential the command has just committed to. Trimmed on both sides, because
+ * a key read from a file or a pipe arrives with a trailing newline.
+ */
+declare const isSameCredential: (existingKey: string | undefined, replacementKey: string | undefined) => boolean;
+//#endregion
+export { API_KEY, CredentialKind, CredentialLocation, CredentialsRead, InterpretedCredentials, KeyScope, OAUTH, StoredCredentials, apiKeyCredentials, credentialKind, describeScope, inspectCredentials, interpretCredentials, isSameCredential, readCredentials, scopeOf, writeCredentials };
+//# sourceMappingURL=credentials.d.ts.map

package/dist/_shared/credentials.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"credentials.d.ts","names":[],"sources":["../../src/_shared/credentials.ts"],"mappings":";;AAgDA;AACA;AAEA;AAA0B;AAAU;AAAe;AAAO;AAO1D;AAwBA;AAiBA;AAaC;AAZa;AACT;AACF;AAUF;AAYD;AAAkC;AAChB;AACA;AAAK;AASvB;AAYC;AAXa;AACT;AACF;AASF;AAUD;AAaA;AAiDA;AAQC;AAPI;AACF;AAAiB;AAQpB;AAQA;AAYA;AAiBE;AAjBgC;AAAA;AAAA;AAAA;AASzB;AACL;AAOF,cA1NW,KAAA,GA0NX,OAAA;AAGW,cA5NA,OAAA,GAmOX,SAAA;AAAA,KAjOU,cAAA,GAiOV,OAjOkC,KAiOlC,GAAA,OAjOiD,OAiOjD;AAPmC;AAAoB;AAOvD;AAGF;AAmBA;KAhPY,iBAAA;;;;;;;;;;;;;;;;;;;;;;;KAwBA,kBAAA;;;;;;;;;;;;;;;;cAiBC,8BACC,uBACT,uBACF;;KAsBS,sBAAA;eACM;;;eACA;;;;;;;;;cASL,oCACC,uBACT,uBACF;;;;;;;;;KAmBS,eAAA;;eACkB;;;;;;;;;;;;;;;cAYjB,sCAAqC;;;;;;;;;;;;;cAiDrC,sBACR,uBACF;cAQU,8CAEC;;KAMF,QAAA;;;;;;;;;;;cAYC;;;;;;;;;UASJ;MACL;;cAUS,uBAAwB,sBAAoB;;cAU5C,uBAAwB;;;;;;;;cAmBxB"}

package/dist/_shared/credentials.js

@@ -1,3 +1,4 @@
+import { writeSecretFile } from "./secure_file.js";
 import { readFileSync } from "node:fs";
 //#region src/_shared/credentials.ts
 /**
@@ -120,12 +121,70 @@ const inspectCredentials = (path) => {
 		credentials: parsed
 	};
 };
+/**
+* The credential at `path`, or `null` when the file is not there.
+*
+* A damaged file is an error, not an absence. Treating it as absent — which is what this used to
+* do — meant any read-only command could repair it by starting a browser sign-in and overwriting
+* it, **possibly as a different account**, with the user never having asked for a repair and no
+* way back to whatever was in the file. Failing here costs one deliberate command; the message
+* names it.
+*
+* `profile list` and telemetry use {@link inspectCredentials} instead, because describing a
+* broken credential is not the same as using one.
+*/
+const readCredentials = (at) => {
+	const read = inspectCredentials(at.path);
+	if (read.kind === "unusable") throw new Error(`${read.reason}. ${repair(at)}`);
+	return read.kind === "ok" ? read.credentials : null;
+};
+const writeCredentials = (path, credentials) => {
+	writeSecretFile(path, JSON.stringify(credentials));
+};
+/**
+* Build an `api_key` credentials object. Nothing from a previous credential is carried over.
+*
+* The scope is stored because it is not recoverable from the secret: `rotate-key` has to mint
+* the replacement on the same endpoint, and an org or project key minted as an account key
+* would silently widen what the profile reaches.
+*/
+const apiKeyCredentials = ({ apiKey, keyId, userId, scope }) => ({
+	type: API_KEY,
+	api_key: apiKey,
+	...keyId !== void 0 ? { key_id: keyId } : {},
+	...userId !== void 0 ? { user_id: userId } : {},
+	...scope?.orgId !== void 0 ? { org_id: scope.orgId } : {},
+	...scope?.projectId !== void 0 ? { project_id: scope.projectId } : {}
+});
+/** The scope recorded on a stored credential. */
+const scopeOf = (credentials) => ({
+	...typeof credentials.org_id === "string" ? { orgId: credentials.org_id } : {},
+	...typeof credentials.project_id === "string" ? { projectId: credentials.project_id } : {}
+});
+/** How to describe a scope in output. */
+const describeScope = (scope) => {
+	if (scope.projectId !== void 0) return `project ${scope.projectId}`;
+	if (scope.orgId !== void 0) return `org ${scope.orgId}`;
+	return "account";
+};
 function nonEmpty(value) {
 	if (typeof value !== "string") return void 0;
 	const trimmed = value.trim();
 	return trimmed === "" ? void 0 : trimmed;
 }
+/**
+* Whether a stored credential is the same secret as the one about to replace it.
+*
+* Re-storing the key a profile already holds is a no-op, not a replacement — and retiring it
+* would revoke the credential the command has just committed to. Trimmed on both sides, because
+* a key read from a file or a pipe arrives with a trailing newline.
+*/
+const isSameCredential = (existingKey, replacementKey) => {
+	if (existingKey === void 0 || replacementKey === void 0) return false;
+	const trimmed = existingKey.trim();
+	return trimmed !== "" && trimmed === replacementKey.trim();
+};
 //#endregion
-export { API_KEY, OAUTH, credentialKind, inspectCredentials, interpretCredentials };
+export { API_KEY, OAUTH, apiKeyCredentials, credentialKind, describeScope, inspectCredentials, interpretCredentials, isSameCredential, readCredentials, scopeOf, writeCredentials };
 
 //# sourceMappingURL=credentials.js.map

package/dist/_shared/credentials.js.map

@@ -1 +1 @@
-{"version":3,"file":"credentials.js","names":[],"sources":["../../src/_shared/credentials.ts"],"sourcesContent":["/**\n * # Stored credentials — one file per account, two kinds\n *\n * A profile points at exactly one credentials file (see `./profiles.ts`), and that file says\n * what kind of credential it holds. Adding API-key support this way rather than adding a\n * second pointer to `profiles.json` keeps a profile what it already was — one name, one path\n * — and means `profiles.json` needs no schema change at all.\n *\n * ```json\n * // oauth: every file written before this existed. An absent `type` means this.\n * { \"access_token\": \"…\", \"refresh_token\": \"…\", \"expires_at\": 1786…, \"user_id\": \"…\" }\n *\n * // api_key, stored by `neon profile create --api-key`\n * { \"type\": \"api_key\", \"api_key\": \"napi_…\", \"user_id\": \"…\" }\n *\n * // api_key minted by `--mint --org-id`, which records the scope it was issued at\n * { \"type\": \"api_key\", \"api_key\": \"napi_…\", \"key_id\": 123, \"org_id\": \"org-…\" }\n * ```\n *\n * ## One profile, one kind\n *\n * A credentials file holds an API key or an OAuth session, never both, and `type` states\n * which. An earlier draft let the two coexist — the idea being that a key could keep the\n * session it was minted from and so rotate without a browser. It did not survive review, for\n * two reasons that are worth recording so nobody rebuilds it:\n *\n * 1. **It never worked.** The resolver returned the key without testing it, so a revoked key\n *    failed to mint and never fell back to the session sitting beside it.\n * 2. **It could mix accounts.** Nothing compared the identity of the credential being written\n *    with the one already there, so a profile could hold one account's session and another's\n *    key, told apart only by a single string. Flip or lose `type` and the profile silently\n *    becomes a different person.\n *\n * Recovery from a dead key is therefore one browser login — `neon profile create <name>\n * --mint --force` — which is what the retained session was supposed to save and never did.\n *\n * ## Older releases\n *\n * A CLI predating this reads the pointer, finds no `type` it understands, ignores it, and\n * looks for `access_token`. An `api_key` profile has none, so an older release falls through\n * to its browser login rather than crashing. That it does not crash is why `credentials`\n * stays a required pointer: an entry without one makes 2.41 and 2.42 throw\n * `ERR_INVALID_ARG_TYPE` from `resolveEntryPath`.\n */\n\nimport { readFileSync } from \"node:fs\";\nimport { writeSecretFile } from \"./secure_file.js\";\n\nexport const OAUTH = \"oauth\";\nexport const API_KEY = \"api_key\";\n\nexport type CredentialKind = typeof OAUTH | typeof API_KEY;\n\n/**\n * The on-disk shape. Every field is optional because the two kinds overlap and because an\n * OAuth token endpoint response carries more than we name here — the index signature keeps\n * those extra fields on a round-trip rather than dropping them.\n */\nexport type StoredCredentials = {\n\ttype?: string;\n\tapi_key?: string;\n\tkey_id?: number;\n\t/** Set when the key was minted for an organization rather than the account. */\n\torg_id?: string;\n\t/** Set when the key was narrowed to a single project. Implies `org_id`. */\n\tproject_id?: string;\n\tuser_id?: string;\n\taccess_token?: string;\n\trefresh_token?: string;\n\texpires_at?: number;\n\t[key: string]: unknown;\n};\n\n/**\n * Where a credential lives, and which profile points at it.\n *\n * Both halves are needed to report a broken file: the path says which file to open, and the\n * profile is what every recovery command takes as its argument. Carrying only the path is what\n * produced errors telling the user to run `neon profile create <name> --force` with the\n * placeholder intact — a command an agent will run verbatim and be told `Invalid profile name\n * \"<name>\"`.\n */\nexport type CredentialLocation = {\n\tpath: string;\n\tprofile: string;\n};\n\n/**\n * Which credential in this file authenticates, by declaration alone.\n *\n * An unrecognised `type` throws rather than falling back to `oauth`. A file we cannot\n * interpret is a misconfiguration the user has to see: treating it as OAuth would send them\n * to a browser login that silently replaces a credential they meant to keep, and treating it\n * as an API key would authenticate with whatever `api_key` happened to be there.\n *\n * This deliberately does not check that an `api_key` file has a key — `neon profile list`\n * needs the kind of a file it is not about to authenticate with, and must be able to report a\n * broken one rather than throwing halfway through a table.\n */\nexport const credentialKind = (\n\tcredentials: StoredCredentials,\n\tat: CredentialLocation,\n): CredentialKind => {\n\tconst declared = credentials.type;\n\tif (declared === undefined || declared === OAUTH) return OAUTH;\n\tif (declared === API_KEY) return API_KEY;\n\t// The value is not quoted back. Everything in this file is secret material, and a\n\t// corrupted or hand-edited file can put a key anywhere in it — including here. Naming the\n\t// file is enough to act on, and it cannot leak what the file holds.\n\tthrow new Error(\n\t\t`${at.path} declares a \"type\" this version does not understand. Expected \"${OAUTH}\" or \"${API_KEY}\". ${repair(at)}`,\n\t);\n};\n\n/**\n * The way out of a credentials file that cannot be read.\n *\n * One sentence, shared by every such error, because they all have the same two answers: write\n * a new credential over it, or delete it and start again.\n */\nconst repair = (at: CredentialLocation): string =>\n\t`Replace it deliberately with \\`neon profile create ${at.profile} --force\\`, or delete the file.`;\n\n/** A credentials file resolved far enough to authenticate with. */\nexport type InterpretedCredentials =\n\t| { kind: typeof API_KEY; apiKey: string }\n\t| { kind: typeof OAUTH };\n\n/**\n * Resolve what to authenticate with, validating that the declared kind is actually usable.\n *\n * An `api_key` file with no key is a hard error rather than a fall-through to OAuth: the user\n * asked for a key, and quietly opening a browser instead would replace the credential they\n * were trying to fix.\n */\nexport const interpretCredentials = (\n\tcredentials: StoredCredentials,\n\tat: CredentialLocation,\n): InterpretedCredentials => {\n\tif (credentialKind(credentials, at) === OAUTH) return { kind: OAUTH };\n\tconst apiKey = nonEmpty(credentials.api_key);\n\tif (apiKey === undefined) {\n\t\tthrow new Error(\n\t\t\t`${at.path} declares \"type\": \"${API_KEY}\" but has no \"api_key\" value. ${repair(at)}`,\n\t\t);\n\t}\n\treturn { kind: API_KEY, apiKey };\n};\n\n/**\n * Read a credentials file, or `null` when there is nothing usable there.\n *\n * Missing and unparseable both return `null`, because both are recoverable by authenticating\n * again and the callers already treat \"no credentials\" as \"log in\". A file that parses but\n * contradicts itself is different — {@link credentialKind} throws for that, since re-running\n * `auth` would paper over a mistake rather than fix it.\n */\nexport type CredentialsRead =\n\t| { kind: \"ok\"; credentials: StoredCredentials }\n\t| { kind: \"absent\" }\n\t/** The file is there but cannot be understood. `reason` is safe to print. */\n\t| { kind: \"unusable\"; reason: string };\n\n/**\n * Read and classify a credentials file, without deciding what to do about it.\n *\n * A permission or I/O error still throws: there may be a perfectly good credential here that\n * we cannot see, and treating that as absent would send the user to a browser login that\n * overwrites it.\n */\nexport const inspectCredentials = (path: string): CredentialsRead => {\n\tlet contents: string;\n\ttry {\n\t\tcontents = readFileSync(path, \"utf8\");\n\t} catch (err) {\n\t\tif ((err as NodeJS.ErrnoException).code === \"ENOENT\")\n\t\t\treturn { kind: \"absent\" };\n\t\tthrow err;\n\t}\n\n\tlet parsed: unknown;\n\ttry {\n\t\tparsed = JSON.parse(contents);\n\t} catch {\n\t\t// The parser's message is deliberately discarded. V8 quotes a window of the input\n\t\t// around the syntax error — on Node 24 a truncated credentials file produced\n\t\t// `Unexpected token 'a', ...\"api_key\":napi_SUPERS\"... is not valid JSON` — and this\n\t\t// reason is printed by `profile list` and by every failed authentication. A malformed\n\t\t// secret file is exactly when a diagnostic must say less, not more.\n\t\treturn {\n\t\t\tkind: \"unusable\",\n\t\t\treason: `${path} is not valid JSON, so the credential in it cannot be read`,\n\t\t};\n\t}\n\tif (\n\t\tparsed === null ||\n\t\ttypeof parsed !== \"object\" ||\n\t\tArray.isArray(parsed)\n\t) {\n\t\treturn {\n\t\t\tkind: \"unusable\",\n\t\t\treason: `${path} does not contain a credentials object`,\n\t\t};\n\t}\n\treturn { kind: \"ok\", credentials: parsed as StoredCredentials };\n};\n\n/**\n * The credential at `path`, or `null` when the file is not there.\n *\n * A damaged file is an error, not an absence. Treating it as absent — which is what this used to\n * do — meant any read-only command could repair it by starting a browser sign-in and overwriting\n * it, **possibly as a different account**, with the user never having asked for a repair and no\n * way back to whatever was in the file. Failing here costs one deliberate command; the message\n * names it.\n *\n * `profile list` and telemetry use {@link inspectCredentials} instead, because describing a\n * broken credential is not the same as using one.\n */\nexport const readCredentials = (\n\tat: CredentialLocation,\n): StoredCredentials | null => {\n\tconst read = inspectCredentials(at.path);\n\tif (read.kind === \"unusable\") {\n\t\tthrow new Error(`${read.reason}. ${repair(at)}`);\n\t}\n\treturn read.kind === \"ok\" ? read.credentials : null;\n};\n\nexport const writeCredentials = (\n\tpath: string,\n\tcredentials: StoredCredentials,\n): void => {\n\twriteSecretFile(path, JSON.stringify(credentials));\n};\n\n/** The scope a minted key was issued at. Absent org means an account key. */\nexport type KeyScope = {\n\torgId?: string;\n\tprojectId?: string;\n};\n\n/**\n * Build an `api_key` credentials object. Nothing from a previous credential is carried over.\n *\n * The scope is stored because it is not recoverable from the secret: `rotate-key` has to mint\n * the replacement on the same endpoint, and an org or project key minted as an account key\n * would silently widen what the profile reaches.\n */\nexport const apiKeyCredentials = ({\n\tapiKey,\n\tkeyId,\n\tuserId,\n\tscope,\n}: {\n\tapiKey: string;\n\tkeyId?: number;\n\tuserId?: string;\n\tscope?: KeyScope;\n}): StoredCredentials => ({\n\ttype: API_KEY,\n\tapi_key: apiKey,\n\t...(keyId !== undefined ? { key_id: keyId } : {}),\n\t...(userId !== undefined ? { user_id: userId } : {}),\n\t...(scope?.orgId !== undefined ? { org_id: scope.orgId } : {}),\n\t...(scope?.projectId !== undefined ? { project_id: scope.projectId } : {}),\n});\n\n/** The scope recorded on a stored credential. */\nexport const scopeOf = (credentials: StoredCredentials): KeyScope => ({\n\t...(typeof credentials.org_id === \"string\"\n\t\t? { orgId: credentials.org_id }\n\t\t: {}),\n\t...(typeof credentials.project_id === \"string\"\n\t\t? { projectId: credentials.project_id }\n\t\t: {}),\n});\n\n/** How to describe a scope in output. */\nexport const describeScope = (scope: KeyScope): string => {\n\tif (scope.projectId !== undefined) return `project ${scope.projectId}`;\n\tif (scope.orgId !== undefined) return `org ${scope.orgId}`;\n\treturn \"account\";\n};\n\nfunction nonEmpty(value: unknown): string | undefined {\n\tif (typeof value !== \"string\") return undefined;\n\tconst trimmed = value.trim();\n\treturn trimmed === \"\" ? undefined : trimmed;\n}\n\n/**\n * Whether a stored credential is the same secret as the one about to replace it.\n *\n * Re-storing the key a profile already holds is a no-op, not a replacement — and retiring it\n * would revoke the credential the command has just committed to. Trimmed on both sides, because\n * a key read from a file or a pipe arrives with a trailing newline.\n */\nexport const isSameCredential = (\n\texistingKey: string | undefined,\n\treplacementKey: string | undefined,\n): boolean => {\n\tif (existingKey === undefined || replacementKey === undefined) return false;\n\tconst trimmed = existingKey.trim();\n\treturn trimmed !== \"\" && trimmed === replacementKey.trim();\n};\n"],"mappings":";;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;AAgDA,MAAa,QAAQ;AACrB,MAAa,UAAU;;;;;;;;;;;;;AAkDvB,MAAa,kBACZ,aACA,OACoB;CACpB,MAAM,WAAW,YAAY;CAC7B,IAAI,aAAa,KAAA,KAAa,aAAA,SAAoB,OAAO;CACzD,IAAI,aAAA,WAAsB,OAAO;CAIjC,MAAM,IAAI,MACT,GAAG,GAAG,KAAK,iEAAiE,MAAM,QAAQ,QAAQ,KAAK,OAAO,EAAE,GACjH;AACD;;;;;;;AAQA,MAAM,UAAU,OACf,sDAAsD,GAAG,QAAQ;;;;;;;;AAclE,MAAa,wBACZ,aACA,OAC4B;CAC5B,IAAI,eAAe,aAAa,EAAE,MAAA,SAAa,OAAO,EAAE,MAAM,MAAM;CACpE,MAAM,SAAS,SAAS,YAAY,OAAO;CAC3C,IAAI,WAAW,KAAA,GACd,MAAM,IAAI,MACT,GAAG,GAAG,KAAK,qBAAqB,QAAQ,gCAAgC,OAAO,EAAE,GAClF;CAED,OAAO;EAAE,MAAM;EAAS;CAAO;AAChC;;;;;;;;AAuBA,MAAa,sBAAsB,SAAkC;CACpE,IAAI;CACJ,IAAI;EACH,WAAW,aAAa,MAAM,MAAM;CACrC,SAAS,KAAK;EACb,IAAK,IAA8B,SAAS,UAC3C,OAAO,EAAE,MAAM,SAAS;EACzB,MAAM;CACP;CAEA,IAAI;CACJ,IAAI;EACH,SAAS,KAAK,MAAM,QAAQ;CAC7B,QAAQ;EAMP,OAAO;GACN,MAAM;GACN,QAAQ,GAAG,KAAK;EACjB;CACD;CACA,IACC,WAAW,QACX,OAAO,WAAW,YAClB,MAAM,QAAQ,MAAM,GAEpB,OAAO;EACN,MAAM;EACN,QAAQ,GAAG,KAAK;CACjB;CAED,OAAO;EAAE,MAAM;EAAM,aAAa;CAA4B;AAC/D;AAgFA,SAAS,SAAS,OAAoC;CACrD,IAAI,OAAO,UAAU,UAAU,OAAO,KAAA;CACtC,MAAM,UAAU,MAAM,KAAK;CAC3B,OAAO,YAAY,KAAK,KAAA,IAAY;AACrC"}
+{"version":3,"file":"credentials.js","names":[],"sources":["../../src/_shared/credentials.ts"],"sourcesContent":["/**\n * # Stored credentials — one file per account, two kinds\n *\n * A profile points at exactly one credentials file (see `./profiles.ts`), and that file says\n * what kind of credential it holds. Adding API-key support this way rather than adding a\n * second pointer to `profiles.json` keeps a profile what it already was — one name, one path\n * — and means `profiles.json` needs no schema change at all.\n *\n * ```json\n * // oauth: every file written before this existed. An absent `type` means this.\n * { \"access_token\": \"…\", \"refresh_token\": \"…\", \"expires_at\": 1786…, \"user_id\": \"…\" }\n *\n * // api_key, stored by `neon profile create --api-key`\n * { \"type\": \"api_key\", \"api_key\": \"napi_…\", \"user_id\": \"…\" }\n *\n * // api_key minted by `--mint --org-id`, which records the scope it was issued at\n * { \"type\": \"api_key\", \"api_key\": \"napi_…\", \"key_id\": 123, \"org_id\": \"org-…\" }\n * ```\n *\n * ## One profile, one kind\n *\n * A credentials file holds an API key or an OAuth session, never both, and `type` states\n * which. An earlier draft let the two coexist — the idea being that a key could keep the\n * session it was minted from and so rotate without a browser. It did not survive review, for\n * two reasons that are worth recording so nobody rebuilds it:\n *\n * 1. **It never worked.** The resolver returned the key without testing it, so a revoked key\n *    failed to mint and never fell back to the session sitting beside it.\n * 2. **It could mix accounts.** Nothing compared the identity of the credential being written\n *    with the one already there, so a profile could hold one account's session and another's\n *    key, told apart only by a single string. Flip or lose `type` and the profile silently\n *    becomes a different person.\n *\n * Recovery from a dead key is therefore one browser login — `neon profile create <name>\n * --mint --force` — which is what the retained session was supposed to save and never did.\n *\n * ## Older releases\n *\n * A CLI predating this reads the pointer, finds no `type` it understands, ignores it, and\n * looks for `access_token`. An `api_key` profile has none, so an older release falls through\n * to its browser login rather than crashing. That it does not crash is why `credentials`\n * stays a required pointer: an entry without one makes 2.41 and 2.42 throw\n * `ERR_INVALID_ARG_TYPE` from `resolveEntryPath`.\n */\n\nimport { readFileSync } from \"node:fs\";\nimport { writeSecretFile } from \"./secure_file.js\";\n\nexport const OAUTH = \"oauth\";\nexport const API_KEY = \"api_key\";\n\nexport type CredentialKind = typeof OAUTH | typeof API_KEY;\n\n/**\n * The on-disk shape. Every field is optional because the two kinds overlap and because an\n * OAuth token endpoint response carries more than we name here — the index signature keeps\n * those extra fields on a round-trip rather than dropping them.\n */\nexport type StoredCredentials = {\n\ttype?: string;\n\tapi_key?: string;\n\tkey_id?: number;\n\t/** Set when the key was minted for an organization rather than the account. */\n\torg_id?: string;\n\t/** Set when the key was narrowed to a single project. Implies `org_id`. */\n\tproject_id?: string;\n\tuser_id?: string;\n\taccess_token?: string;\n\trefresh_token?: string;\n\texpires_at?: number;\n\t[key: string]: unknown;\n};\n\n/**\n * Where a credential lives, and which profile points at it.\n *\n * Both halves are needed to report a broken file: the path says which file to open, and the\n * profile is what every recovery command takes as its argument. Carrying only the path is what\n * produced errors telling the user to run `neon profile create <name> --force` with the\n * placeholder intact — a command an agent will run verbatim and be told `Invalid profile name\n * \"<name>\"`.\n */\nexport type CredentialLocation = {\n\tpath: string;\n\tprofile: string;\n};\n\n/**\n * Which credential in this file authenticates, by declaration alone.\n *\n * An unrecognised `type` throws rather than falling back to `oauth`. A file we cannot\n * interpret is a misconfiguration the user has to see: treating it as OAuth would send them\n * to a browser login that silently replaces a credential they meant to keep, and treating it\n * as an API key would authenticate with whatever `api_key` happened to be there.\n *\n * This deliberately does not check that an `api_key` file has a key — `neon profile list`\n * needs the kind of a file it is not about to authenticate with, and must be able to report a\n * broken one rather than throwing halfway through a table.\n */\nexport const credentialKind = (\n\tcredentials: StoredCredentials,\n\tat: CredentialLocation,\n): CredentialKind => {\n\tconst declared = credentials.type;\n\tif (declared === undefined || declared === OAUTH) return OAUTH;\n\tif (declared === API_KEY) return API_KEY;\n\t// The value is not quoted back. Everything in this file is secret material, and a\n\t// corrupted or hand-edited file can put a key anywhere in it — including here. Naming the\n\t// file is enough to act on, and it cannot leak what the file holds.\n\tthrow new Error(\n\t\t`${at.path} declares a \"type\" this version does not understand. Expected \"${OAUTH}\" or \"${API_KEY}\". ${repair(at)}`,\n\t);\n};\n\n/**\n * The way out of a credentials file that cannot be read.\n *\n * One sentence, shared by every such error, because they all have the same two answers: write\n * a new credential over it, or delete it and start again.\n */\nconst repair = (at: CredentialLocation): string =>\n\t`Replace it deliberately with \\`neon profile create ${at.profile} --force\\`, or delete the file.`;\n\n/** A credentials file resolved far enough to authenticate with. */\nexport type InterpretedCredentials =\n\t| { kind: typeof API_KEY; apiKey: string }\n\t| { kind: typeof OAUTH };\n\n/**\n * Resolve what to authenticate with, validating that the declared kind is actually usable.\n *\n * An `api_key` file with no key is a hard error rather than a fall-through to OAuth: the user\n * asked for a key, and quietly opening a browser instead would replace the credential they\n * were trying to fix.\n */\nexport const interpretCredentials = (\n\tcredentials: StoredCredentials,\n\tat: CredentialLocation,\n): InterpretedCredentials => {\n\tif (credentialKind(credentials, at) === OAUTH) return { kind: OAUTH };\n\tconst apiKey = nonEmpty(credentials.api_key);\n\tif (apiKey === undefined) {\n\t\tthrow new Error(\n\t\t\t`${at.path} declares \"type\": \"${API_KEY}\" but has no \"api_key\" value. ${repair(at)}`,\n\t\t);\n\t}\n\treturn { kind: API_KEY, apiKey };\n};\n\n/**\n * Read a credentials file, or `null` when there is nothing usable there.\n *\n * Missing and unparseable both return `null`, because both are recoverable by authenticating\n * again and the callers already treat \"no credentials\" as \"log in\". A file that parses but\n * contradicts itself is different — {@link credentialKind} throws for that, since re-running\n * `auth` would paper over a mistake rather than fix it.\n */\nexport type CredentialsRead =\n\t| { kind: \"ok\"; credentials: StoredCredentials }\n\t| { kind: \"absent\" }\n\t/** The file is there but cannot be understood. `reason` is safe to print. */\n\t| { kind: \"unusable\"; reason: string };\n\n/**\n * Read and classify a credentials file, without deciding what to do about it.\n *\n * A permission or I/O error still throws: there may be a perfectly good credential here that\n * we cannot see, and treating that as absent would send the user to a browser login that\n * overwrites it.\n */\nexport const inspectCredentials = (path: string): CredentialsRead => {\n\tlet contents: string;\n\ttry {\n\t\tcontents = readFileSync(path, \"utf8\");\n\t} catch (err) {\n\t\tif ((err as NodeJS.ErrnoException).code === \"ENOENT\")\n\t\t\treturn { kind: \"absent\" };\n\t\tthrow err;\n\t}\n\n\tlet parsed: unknown;\n\ttry {\n\t\tparsed = JSON.parse(contents);\n\t} catch {\n\t\t// The parser's message is deliberately discarded. V8 quotes a window of the input\n\t\t// around the syntax error — on Node 24 a truncated credentials file produced\n\t\t// `Unexpected token 'a', ...\"api_key\":napi_SUPERS\"... is not valid JSON` — and this\n\t\t// reason is printed by `profile list` and by every failed authentication. A malformed\n\t\t// secret file is exactly when a diagnostic must say less, not more.\n\t\treturn {\n\t\t\tkind: \"unusable\",\n\t\t\treason: `${path} is not valid JSON, so the credential in it cannot be read`,\n\t\t};\n\t}\n\tif (\n\t\tparsed === null ||\n\t\ttypeof parsed !== \"object\" ||\n\t\tArray.isArray(parsed)\n\t) {\n\t\treturn {\n\t\t\tkind: \"unusable\",\n\t\t\treason: `${path} does not contain a credentials object`,\n\t\t};\n\t}\n\treturn { kind: \"ok\", credentials: parsed as StoredCredentials };\n};\n\n/**\n * The credential at `path`, or `null` when the file is not there.\n *\n * A damaged file is an error, not an absence. Treating it as absent — which is what this used to\n * do — meant any read-only command could repair it by starting a browser sign-in and overwriting\n * it, **possibly as a different account**, with the user never having asked for a repair and no\n * way back to whatever was in the file. Failing here costs one deliberate command; the message\n * names it.\n *\n * `profile list` and telemetry use {@link inspectCredentials} instead, because describing a\n * broken credential is not the same as using one.\n */\nexport const readCredentials = (\n\tat: CredentialLocation,\n): StoredCredentials | null => {\n\tconst read = inspectCredentials(at.path);\n\tif (read.kind === \"unusable\") {\n\t\tthrow new Error(`${read.reason}. ${repair(at)}`);\n\t}\n\treturn read.kind === \"ok\" ? read.credentials : null;\n};\n\nexport const writeCredentials = (\n\tpath: string,\n\tcredentials: StoredCredentials,\n): void => {\n\twriteSecretFile(path, JSON.stringify(credentials));\n};\n\n/** The scope a minted key was issued at. Absent org means an account key. */\nexport type KeyScope = {\n\torgId?: string;\n\tprojectId?: string;\n};\n\n/**\n * Build an `api_key` credentials object. Nothing from a previous credential is carried over.\n *\n * The scope is stored because it is not recoverable from the secret: `rotate-key` has to mint\n * the replacement on the same endpoint, and an org or project key minted as an account key\n * would silently widen what the profile reaches.\n */\nexport const apiKeyCredentials = ({\n\tapiKey,\n\tkeyId,\n\tuserId,\n\tscope,\n}: {\n\tapiKey: string;\n\tkeyId?: number;\n\tuserId?: string;\n\tscope?: KeyScope;\n}): StoredCredentials => ({\n\ttype: API_KEY,\n\tapi_key: apiKey,\n\t...(keyId !== undefined ? { key_id: keyId } : {}),\n\t...(userId !== undefined ? { user_id: userId } : {}),\n\t...(scope?.orgId !== undefined ? { org_id: scope.orgId } : {}),\n\t...(scope?.projectId !== undefined ? { project_id: scope.projectId } : {}),\n});\n\n/** The scope recorded on a stored credential. */\nexport const scopeOf = (credentials: StoredCredentials): KeyScope => ({\n\t...(typeof credentials.org_id === \"string\"\n\t\t? { orgId: credentials.org_id }\n\t\t: {}),\n\t...(typeof credentials.project_id === \"string\"\n\t\t? { projectId: credentials.project_id }\n\t\t: {}),\n});\n\n/** How to describe a scope in output. */\nexport const describeScope = (scope: KeyScope): string => {\n\tif (scope.projectId !== undefined) return `project ${scope.projectId}`;\n\tif (scope.orgId !== undefined) return `org ${scope.orgId}`;\n\treturn \"account\";\n};\n\nfunction nonEmpty(value: unknown): string | undefined {\n\tif (typeof value !== \"string\") return undefined;\n\tconst trimmed = value.trim();\n\treturn trimmed === \"\" ? undefined : trimmed;\n}\n\n/**\n * Whether a stored credential is the same secret as the one about to replace it.\n *\n * Re-storing the key a profile already holds is a no-op, not a replacement — and retiring it\n * would revoke the credential the command has just committed to. Trimmed on both sides, because\n * a key read from a file or a pipe arrives with a trailing newline.\n */\nexport const isSameCredential = (\n\texistingKey: string | undefined,\n\treplacementKey: string | undefined,\n): boolean => {\n\tif (existingKey === undefined || replacementKey === undefined) return false;\n\tconst trimmed = existingKey.trim();\n\treturn trimmed !== \"\" && trimmed === replacementKey.trim();\n};\n"],"mappings":";;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;AAgDA,MAAa,QAAQ;AACrB,MAAa,UAAU;;;;;;;;;;;;;AAkDvB,MAAa,kBACZ,aACA,OACoB;CACpB,MAAM,WAAW,YAAY;CAC7B,IAAI,aAAa,KAAA,KAAa,aAAA,SAAoB,OAAO;CACzD,IAAI,aAAA,WAAsB,OAAO;CAIjC,MAAM,IAAI,MACT,GAAG,GAAG,KAAK,iEAAiE,MAAM,QAAQ,QAAQ,KAAK,OAAO,EAAE,GACjH;AACD;;;;;;;AAQA,MAAM,UAAU,OACf,sDAAsD,GAAG,QAAQ;;;;;;;;AAclE,MAAa,wBACZ,aACA,OAC4B;CAC5B,IAAI,eAAe,aAAa,EAAE,MAAA,SAAa,OAAO,EAAE,MAAM,MAAM;CACpE,MAAM,SAAS,SAAS,YAAY,OAAO;CAC3C,IAAI,WAAW,KAAA,GACd,MAAM,IAAI,MACT,GAAG,GAAG,KAAK,qBAAqB,QAAQ,gCAAgC,OAAO,EAAE,GAClF;CAED,OAAO;EAAE,MAAM;EAAS;CAAO;AAChC;;;;;;;;AAuBA,MAAa,sBAAsB,SAAkC;CACpE,IAAI;CACJ,IAAI;EACH,WAAW,aAAa,MAAM,MAAM;CACrC,SAAS,KAAK;EACb,IAAK,IAA8B,SAAS,UAC3C,OAAO,EAAE,MAAM,SAAS;EACzB,MAAM;CACP;CAEA,IAAI;CACJ,IAAI;EACH,SAAS,KAAK,MAAM,QAAQ;CAC7B,QAAQ;EAMP,OAAO;GACN,MAAM;GACN,QAAQ,GAAG,KAAK;EACjB;CACD;CACA,IACC,WAAW,QACX,OAAO,WAAW,YAClB,MAAM,QAAQ,MAAM,GAEpB,OAAO;EACN,MAAM;EACN,QAAQ,GAAG,KAAK;CACjB;CAED,OAAO;EAAE,MAAM;EAAM,aAAa;CAA4B;AAC/D;;;;;;;;;;;;;AAcA,MAAa,mBACZ,OAC8B;CAC9B,MAAM,OAAO,mBAAmB,GAAG,IAAI;CACvC,IAAI,KAAK,SAAS,YACjB,MAAM,IAAI,MAAM,GAAG,KAAK,OAAO,IAAI,OAAO,EAAE,GAAG;CAEhD,OAAO,KAAK,SAAS,OAAO,KAAK,cAAc;AAChD;AAEA,MAAa,oBACZ,MACA,gBACU;CACV,gBAAgB,MAAM,KAAK,UAAU,WAAW,CAAC;AAClD;;;;;;;;AAeA,MAAa,qBAAqB,EACjC,QACA,OACA,QACA,aAMyB;CACzB,MAAM;CACN,SAAS;CACT,GAAI,UAAU,KAAA,IAAY,EAAE,QAAQ,MAAM,IAAI,CAAC;CAC/C,GAAI,WAAW,KAAA,IAAY,EAAE,SAAS,OAAO,IAAI,CAAC;CAClD,GAAI,OAAO,UAAU,KAAA,IAAY,EAAE,QAAQ,MAAM,MAAM,IAAI,CAAC;CAC5D,GAAI,OAAO,cAAc,KAAA,IAAY,EAAE,YAAY,MAAM,UAAU,IAAI,CAAC;AACzE;;AAGA,MAAa,WAAW,iBAA8C;CACrE,GAAI,OAAO,YAAY,WAAW,WAC/B,EAAE,OAAO,YAAY,OAAO,IAC5B,CAAC;CACJ,GAAI,OAAO,YAAY,eAAe,WACnC,EAAE,WAAW,YAAY,WAAW,IACpC,CAAC;AACL;;AAGA,MAAa,iBAAiB,UAA4B;CACzD,IAAI,MAAM,cAAc,KAAA,GAAW,OAAO,WAAW,MAAM;CAC3D,IAAI,MAAM,UAAU,KAAA,GAAW,OAAO,OAAO,MAAM;CACnD,OAAO;AACR;AAEA,SAAS,SAAS,OAAoC;CACrD,IAAI,OAAO,UAAU,UAAU,OAAO,KAAA;CACtC,MAAM,UAAU,MAAM,KAAK;CAC3B,OAAO,YAAY,KAAK,KAAA,IAAY;AACrC;;;;;;;;AASA,MAAa,oBACZ,aACA,mBACa;CACb,IAAI,gBAAgB,KAAA,KAAa,mBAAmB,KAAA,GAAW,OAAO;CACtE,MAAM,UAAU,YAAY,KAAK;CACjC,OAAO,YAAY,MAAM,YAAY,eAAe,KAAK;AAC1D"}