neonctl 2.29.0 → 2.29.2
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +70 -70
- package/dist/dev/env.js +1 -1
- package/package.json +5 -5
package/README.md
CHANGED
|
@@ -5,7 +5,7 @@ The Neon CLI is a command-line interface that lets you manage [Neon Serverless P
|
|
|
5
5
|
**npm**
|
|
6
6
|
|
|
7
7
|
```shell
|
|
8
|
-
npm i -g
|
|
8
|
+
npm i -g neon
|
|
9
9
|
```
|
|
10
10
|
|
|
11
11
|
Requires Node.js 18.0 or higher.
|
|
@@ -25,7 +25,7 @@ Download a binary file [here](https://github.com/neondatabase/neonctl/releases).
|
|
|
25
25
|
**npm**
|
|
26
26
|
|
|
27
27
|
```shell
|
|
28
|
-
npm update -g
|
|
28
|
+
npm update -g neon
|
|
29
29
|
```
|
|
30
30
|
|
|
31
31
|
Requires Node.js 18.0 or higher.
|
|
@@ -45,15 +45,15 @@ To upgrade a binary version, download the latest binary file, as described above
|
|
|
45
45
|
Run the following command to authenticate a connection to Neon:
|
|
46
46
|
|
|
47
47
|
```bash
|
|
48
|
-
|
|
48
|
+
neon auth
|
|
49
49
|
```
|
|
50
50
|
|
|
51
|
-
The `auth` command launches a browser window where you can authorize the Neon CLI to access your Neon account. Running a Neon CLI command without authenticating with [
|
|
51
|
+
The `auth` command launches a browser window where you can authorize the Neon CLI to access your Neon account. Running a Neon CLI command without authenticating with [neon auth](https://neon.tech/docs/reference/cli-auth) automatically launches the browser authentication process.
|
|
52
52
|
|
|
53
|
-
Alternatively, you can authenticate a connection with a Neon API key using the `--api-key` option when running a Neon CLI command. For example, an API key is used with the following `
|
|
53
|
+
Alternatively, you can authenticate a connection with a Neon API key using the `--api-key` option when running a Neon CLI command. For example, an API key is used with the following `neon projects list` command:
|
|
54
54
|
|
|
55
55
|
```bash
|
|
56
|
-
|
|
56
|
+
neon projects list --api-key <neon_api_key>
|
|
57
57
|
```
|
|
58
58
|
|
|
59
59
|
For information about obtaining an Neon API key, see [Authentication](https://api-docs.neon.tech/reference/authentication), in the _Neon API Reference_.
|
|
@@ -62,20 +62,20 @@ For information about obtaining an Neon API key, see [Authentication](https://ap
|
|
|
62
62
|
|
|
63
63
|
### The `psql` command
|
|
64
64
|
|
|
65
|
-
`
|
|
65
|
+
`neon psql [branch]` opens a psql session against a branch. It builds the connection string for the branch and launches psql — a shortcut for `neon connection-string --psql`. See [Neon CLI commands — psql](https://neon.com/docs/reference/cli-psql) for the full reference.
|
|
66
66
|
|
|
67
67
|
```bash
|
|
68
|
-
|
|
69
|
-
|
|
70
|
-
|
|
71
|
-
|
|
68
|
+
neon psql # default branch
|
|
69
|
+
neon psql main # a specific branch
|
|
70
|
+
neon psql main@2024-01-01T00:00:00Z # point-in-time (branch@timestamp or branch@lsn)
|
|
71
|
+
neon psql --pooled # use the pooled connection
|
|
72
72
|
```
|
|
73
73
|
|
|
74
74
|
Arguments after `--` are forwarded to psql:
|
|
75
75
|
|
|
76
76
|
```bash
|
|
77
|
-
|
|
78
|
-
|
|
77
|
+
neon psql main -- -c "SELECT version()"
|
|
78
|
+
neon psql main -- -f script.sql --csv
|
|
79
79
|
```
|
|
80
80
|
|
|
81
81
|
Options: `--project-id`, `--role-name`, `--database-name`, `--pooled`, `--endpoint-type` (`read_only` | `read_write`), `--ssl`, plus the [global options](#global-options).
|
|
@@ -85,23 +85,23 @@ Options: `--project-id`, `--role-name`, `--database-name`, `--pooled`, `--endpoi
|
|
|
85
85
|
Several other commands accept a `--psql` flag that opens a psql session against the resolved endpoint:
|
|
86
86
|
|
|
87
87
|
```bash
|
|
88
|
-
|
|
89
|
-
|
|
90
|
-
|
|
88
|
+
neon connection-string --psql --project-id <id>
|
|
89
|
+
neon projects create --psql
|
|
90
|
+
neon branches create --psql
|
|
91
91
|
```
|
|
92
92
|
|
|
93
93
|
Any arguments after `--` are forwarded to psql, for example:
|
|
94
94
|
|
|
95
95
|
```bash
|
|
96
|
-
|
|
97
|
-
|
|
96
|
+
neon cs --psql --project-id <id> -- -c "SELECT version()"
|
|
97
|
+
neon cs --psql --project-id <id> -- -f script.sql --csv
|
|
98
98
|
```
|
|
99
99
|
|
|
100
100
|
### Embedded psql fallback
|
|
101
101
|
|
|
102
102
|
If the system has `psql` installed on `$PATH`, `--psql` continues to spawn the native binary — there is no behavior change for existing users.
|
|
103
103
|
|
|
104
|
-
If `psql` is not found on `$PATH`,
|
|
104
|
+
If `psql` is not found on `$PATH`, neon now falls back to an embedded TypeScript implementation. There is nothing to install or configure; it ships with `neon`. This removes the "no psql binary" trap on machines (and CI runners) that don't have PostgreSQL client tools installed.
|
|
105
105
|
|
|
106
106
|
Automatic fallback is the intended path — there is normally no flag to set. The embedded implementation can also be force-selected (primarily for tests and CI, e.g. to exercise it even when a native `psql` is present):
|
|
107
107
|
|
|
@@ -160,15 +160,15 @@ The Neon CLI supports autocompletion, which you can configure in a few easy step
|
|
|
160
160
|
|
|
161
161
|
## Linking a project
|
|
162
162
|
|
|
163
|
-
`
|
|
163
|
+
`neon link` is a Vercel-style command that binds the current directory to a Neon project. It picks (or creates) an organization and a project and writes a `.neon` file (`{ "orgId", "projectId", "branch" }`) that subsequent commands run in this directory (or any sub-directory) pick up automatically.
|
|
164
164
|
|
|
165
165
|
`link` resolves what it can and **verifies every identifier you pass** before writing, so a `.neon` is never left half-written or pointing at something that doesn't exist:
|
|
166
166
|
|
|
167
167
|
- **org** is inferred from the project (so `--project-id` alone is enough); it's omitted only when the project has no organization (personal account).
|
|
168
168
|
- **project** is taken from `--project-id` (or chosen interactively / via `--agent`).
|
|
169
|
-
- **branch** is left to an explicit [`
|
|
169
|
+
- **branch** is left to an explicit [`neon checkout <branch>`](#checkout) — `link` never silently pins a project's default branch (that would make later commands quietly target, say, production). It only records a branch when you pass `--branch`, when one is already pinned for the same project (preserved), when you pick one in the interactive picker, or for a freshly **created** project (whose single branch is unambiguous).
|
|
170
170
|
|
|
171
|
-
When a branch ends up pinned, `link` also runs [`env pull`](#env-pull) so the branch's Neon env vars (`DATABASE_URL`, …) land in a local `.env`. With no branch pinned there is nothing to pull, so `link` instead nudges you to run `
|
|
171
|
+
When a branch ends up pinned, `link` also runs [`env pull`](#env-pull) so the branch's Neon env vars (`DATABASE_URL`, …) land in a local `.env`. With no branch pinned there is nothing to pull, so `link` instead nudges you to run `neon checkout`. Pass `--no-env-pull` to skip the pull (for example when injecting env at runtime with `neon-env run` or `neon dev`).
|
|
172
172
|
|
|
173
173
|
> **Migrating from `set-context`?** `set-context` is **deprecated** in favor of `link` (see [below](#set-context-is-deprecated)). It still works exactly as before for now (a raw write), it just prints a deprecation warning. The `.neon` `branchId` field is also superseded by `branch` (which stores the branch **name** when known); old `branchId` files are still read and are upgraded to `branch` the next time `link`/`checkout` writes the context.
|
|
174
174
|
|
|
@@ -177,7 +177,7 @@ There are three modes:
|
|
|
177
177
|
**Interactive (default)** — guided prompts for humans:
|
|
178
178
|
|
|
179
179
|
```bash
|
|
180
|
-
$
|
|
180
|
+
$ neon link
|
|
181
181
|
? Which organization would you like to link? › Personal Org (org-abc123)
|
|
182
182
|
? Which project would you like to link? › ＋ Create new project…
|
|
183
183
|
? Name for the new project: › my-app
|
|
@@ -191,9 +191,9 @@ Linked .neon:
|
|
|
191
191
|
|
|
192
192
|
When you link an **existing** project that has more than one branch, the interactive flow adds a
|
|
193
193
|
final step to pick which branch to pin — the same `＋ Create a new branch…` + list selector used by
|
|
194
|
-
`
|
|
194
|
+
`neon checkout` (a single-branch project is pinned automatically, no prompt). Non-interactive
|
|
195
195
|
`link --project-id …` does **not** prompt or default a branch; it links org + project and leaves
|
|
196
|
-
branch selection to `
|
|
196
|
+
branch selection to `neon checkout`:
|
|
197
197
|
|
|
198
198
|
```bash
|
|
199
199
|
? Which organization would you like to link? › Personal Org (org-abc123)
|
|
@@ -205,28 +205,28 @@ branch selection to `neonctl checkout`:
|
|
|
205
205
|
|
|
206
206
|
```bash
|
|
207
207
|
# Link to an existing project (org is inferred from the project; no branch pinned)
|
|
208
|
-
|
|
208
|
+
neon link --project-id polished-snowflake-12345678
|
|
209
209
|
|
|
210
210
|
# Same, but also pin a branch (name or id — resolved and stored as its name)
|
|
211
|
-
|
|
211
|
+
neon link --project-id polished-snowflake-12345678 --branch main
|
|
212
212
|
|
|
213
213
|
# Pin/switch the branch in the already-linked project
|
|
214
|
-
|
|
214
|
+
neon link --branch main # alias: --branch-id
|
|
215
215
|
|
|
216
216
|
# Create a new project and link it (pins the new project's default branch)
|
|
217
|
-
|
|
217
|
+
neon link --org-id org-abc123 --project-name my-app --region-id aws-us-east-2
|
|
218
218
|
|
|
219
219
|
# Same payload, one JSON blob
|
|
220
|
-
|
|
220
|
+
neon link --params '{"orgId":"org-abc123","projectName":"my-app","regionId":"aws-us-east-2"}'
|
|
221
221
|
|
|
222
222
|
# Record just the default org (preserves any existing project/branch)
|
|
223
|
-
|
|
223
|
+
neon link --org-id org-abc123
|
|
224
224
|
|
|
225
225
|
# Forget the current context
|
|
226
|
-
|
|
226
|
+
neon link --clear
|
|
227
227
|
|
|
228
228
|
# Offline write — no API calls, no verification (see --no-checks below)
|
|
229
|
-
|
|
229
|
+
neon link --no-checks --org-id org-abc123 --project-id polished-snowflake-12345678
|
|
230
230
|
```
|
|
231
231
|
|
|
232
232
|
Every supplied identifier is checked before anything is written, with actionable errors — e.g. `Project '…' not found`, `You don't have access to project '…'`, `Organization '…' not found, or your API key doesn't have access to it`, `Project '…' belongs to organization 'A', not 'B'`, or `Branch '…' not found in project '…'. Available branches: …`.
|
|
@@ -234,7 +234,7 @@ Every supplied identifier is checked before anything is written, with actionable
|
|
|
234
234
|
**Agent mode (`--agent`)** — a JSON state machine designed for AI coding assistants. Each invocation returns a single JSON object with a `status` discriminator describing the next step, the available options, and the exact follow-up command to run.
|
|
235
235
|
|
|
236
236
|
```bash
|
|
237
|
-
$
|
|
237
|
+
$ neon link --agent
|
|
238
238
|
{
|
|
239
239
|
"status": "needs_org",
|
|
240
240
|
"instruction": "Ask the user which of these 2 organizations they want to link the current directory to. After they pick one, re-run the next_command_template with the chosen --org-id value.",
|
|
@@ -242,10 +242,10 @@ $ neonctl link --agent
|
|
|
242
242
|
{ "id": "org-abc123", "name": "Personal Org" },
|
|
243
243
|
{ "id": "org-team", "name": "Team Org" }
|
|
244
244
|
],
|
|
245
|
-
"next_command_template": "
|
|
245
|
+
"next_command_template": "neon link --agent --org-id <org_id>"
|
|
246
246
|
}
|
|
247
247
|
|
|
248
|
-
$
|
|
248
|
+
$ neon link --agent --org-id org-abc123
|
|
249
249
|
{
|
|
250
250
|
"status": "needs_project",
|
|
251
251
|
"instruction": "Ask the user whether to link to one of these 1 existing projects (use next_command_template with --project-id) or create a new project (use create_option.next_command_template).",
|
|
@@ -254,12 +254,12 @@ $ neonctl link --agent --org-id org-abc123
|
|
|
254
254
|
],
|
|
255
255
|
"create_option": {
|
|
256
256
|
"instruction": "To create a new project, ask the user for a project name. The region can be omitted to receive a follow-up needs_project_details response that lists available regions.",
|
|
257
|
-
"next_command_template": "
|
|
257
|
+
"next_command_template": "neon link --agent --org-id org-abc123 --project-name <name> --region-id <region_id>"
|
|
258
258
|
},
|
|
259
|
-
"next_command_template": "
|
|
259
|
+
"next_command_template": "neon link --agent --org-id org-abc123 --project-id <project_id>"
|
|
260
260
|
}
|
|
261
261
|
|
|
262
|
-
$
|
|
262
|
+
$ neon link --agent --org-id org-abc123 --project-id polished-snowflake-12345678
|
|
263
263
|
{
|
|
264
264
|
"status": "linked",
|
|
265
265
|
"context_file": "/path/to/cwd/.neon",
|
|
@@ -268,7 +268,7 @@ $ neonctl link --agent --org-id org-abc123 --project-id polished-snowflake-12345
|
|
|
268
268
|
"projectId": "polished-snowflake-12345678"
|
|
269
269
|
},
|
|
270
270
|
"project": { "id": "polished-snowflake-12345678" },
|
|
271
|
-
"message": "Linked /path/to/cwd/.neon to project polished-snowflake-12345678 (org org-abc123). No branch pinned — run `
|
|
271
|
+
"message": "Linked /path/to/cwd/.neon to project polished-snowflake-12345678 (org org-abc123). No branch pinned — run `neon checkout <branch>` (omit the branch to list options) to pin one and pull its env vars."
|
|
272
272
|
}
|
|
273
273
|
```
|
|
274
274
|
|
|
@@ -293,7 +293,7 @@ The `linked` response omits `branch` unless one was pinned (via `--branch`, an e
|
|
|
293
293
|
**Offline writes (`--no-checks`)** — write the `.neon` with no API calls at all: no org inference, no existence/access verification, no env pull. Because nothing can be resolved offline, it requires both `--org-id` and `--project-id` (`--branch` optional, stored verbatim). Handy for scripted/CI setups or re-creating a `.neon` from values you already trust:
|
|
294
294
|
|
|
295
295
|
```bash
|
|
296
|
-
|
|
296
|
+
neon link --no-checks --org-id org-abc123 --project-id polished-snowflake-12345678 --branch main
|
|
297
297
|
```
|
|
298
298
|
|
|
299
299
|
#### `set-context` is deprecated
|
|
@@ -304,11 +304,11 @@ How today's `set-context` uses map onto `link`:
|
|
|
304
304
|
|
|
305
305
|
| `set-context` (deprecated) | Recommended `link` equivalent |
|
|
306
306
|
| --------------------------------------- | ----------------------------------------------------------------------------- |
|
|
307
|
-
| `
|
|
308
|
-
| `
|
|
309
|
-
| `
|
|
310
|
-
| `
|
|
311
|
-
| a raw local write (no network) | `
|
|
307
|
+
| `neon set-context --project-id <id>` | `neon link --project-id <id>` (infers org + verifies; branch via checkout) |
|
|
308
|
+
| `neon set-context --org-id <id>` | `neon link --org-id <id>` |
|
|
309
|
+
| `neon set-context --branch-id <id>` | `neon link --branch <name\|id>` |
|
|
310
|
+
| `neon set-context` (clear) | `neon link --clear` |
|
|
311
|
+
| a raw local write (no network) | `neon link --no-checks --org-id <id> --project-id <id>` |
|
|
312
312
|
|
|
313
313
|
The key difference: `link` resolves and **verifies** before writing (so you never get a half-written or stale `.neon`), whereas `set-context` writes whatever you give it verbatim. The closest like-for-like replacement for the old raw write is `link --no-checks`.
|
|
314
314
|
|
|
@@ -316,25 +316,25 @@ The key difference: `link` resolves and **verifies** before writing (so you neve
|
|
|
316
316
|
|
|
317
317
|
`checkout [id|name]` pins a branch in the local context so subsequent commands target it — it's the focused companion to `link` for the common "switch the branch I'm working on" case (`link` resolves org + project; `checkout` pins the branch). It resolves the branch (by name or id) against the project, then **heals** the `.neon` file: it always (re)writes `projectId`, `branch`, and `orgId` (when the project has one), so a `.neon` that was missing fields or drifted ends up complete and consistent. The branch is stored as its **name** when known (matching `link`). When `orgId` isn't already known (from `--org-id` or the existing `.neon`), it's looked up from the project itself.
|
|
318
318
|
|
|
319
|
-
The branch argument is **optional**: run `
|
|
319
|
+
The branch argument is **optional**: run `neon checkout` with no branch in an interactive terminal to fetch the project's branches and pick one from a list. In a non-interactive context (CI or no TTY), a branch must be passed explicitly.
|
|
320
320
|
|
|
321
321
|
Branch **id vs name** is detected automatically (a `br-…` value is treated as an id):
|
|
322
322
|
|
|
323
323
|
- **id** — matched strictly by id. A non-existent id is a hard "not found" error (ids are server-assigned, so checkout never creates one).
|
|
324
|
-
- **name** — matched by name. If the name doesn't exist, in an interactive terminal `checkout` offers to **create** it (equivalent to `
|
|
324
|
+
- **name** — matched by name. If the name doesn't exist, in an interactive terminal `checkout` offers to **create** it (equivalent to `neon branch create --name <name>`: branched from the project's default branch with a read-write compute), then checks it out. In a non-interactive context a missing name is the usual "not found" error.
|
|
325
325
|
|
|
326
|
-
The project is resolved through the standard
|
|
326
|
+
The project is resolved through the standard neon chain, each entry winning over the next:
|
|
327
327
|
|
|
328
328
|
1. `--project-id <id>` flag
|
|
329
329
|
2. `projectId` from the closest `.neon` file (found by walking up from the current directory — see "Where `.neon` lives" below)
|
|
330
330
|
3. If still unresolved and the API key maps to exactly one project, that project is auto-detected (same behaviour as `branches` and `connection-string`)
|
|
331
331
|
|
|
332
|
-
If none of those resolve a project, `checkout` prints a telling error explaining the chain above. In an interactive terminal it then offers to run `
|
|
332
|
+
If none of those resolve a project, `checkout` prints a telling error explaining the chain above. In an interactive terminal it then offers to run `neon link` in the current folder so you can pick (or create) a project on the spot; once linked, it continues and pins the requested branch. In non-interactive contexts (CI or no TTY) it exits with a non-zero code and the same guidance instead of prompting.
|
|
333
333
|
|
|
334
334
|
The resolved branch is then written (by name) to the same `.neon` file `link` uses:
|
|
335
335
|
|
|
336
336
|
```bash
|
|
337
|
-
$
|
|
337
|
+
$ neon checkout main --project-id polished-snowflake-12345678
|
|
338
338
|
INFO: Checked out branch br-main-branch-87654321 on project polished-snowflake-12345678. Updated /path/to/cwd/.neon.
|
|
339
339
|
|
|
340
340
|
$ cat .neon
|
|
@@ -345,7 +345,7 @@ $ cat .neon
|
|
|
345
345
|
}
|
|
346
346
|
```
|
|
347
347
|
|
|
348
|
-
After pinning the branch, `checkout` also runs [`env pull`](#env-pull) by default, so the branch's Neon env vars are written to your local `.env` and you can start building right away — the branch-first loop is just `link` + `checkout`. Pass `--no-env-pull` to skip it (for example when env is injected at runtime via `neon-env run` / `
|
|
348
|
+
After pinning the branch, `checkout` also runs [`env pull`](#env-pull) by default, so the branch's Neon env vars are written to your local `.env` and you can start building right away — the branch-first loop is just `link` + `checkout`. Pass `--no-env-pull` to skip it (for example when env is injected at runtime via `neon-env run` / `neon dev`, or to keep secrets out of the working tree). A pull failure never undoes the checkout: the branch stays pinned and the failure is surfaced as a warning pointing you at `neon env pull` (or `neon deploy` if a `neon.ts`-declared service is missing).
|
|
349
349
|
|
|
350
350
|
### env pull
|
|
351
351
|
|
|
@@ -355,13 +355,13 @@ After pinning the branch, `checkout` also runs [`env pull`](#env-pull) by defaul
|
|
|
355
355
|
|
|
356
356
|
```bash
|
|
357
357
|
# Refresh the linked branch's vars in place
|
|
358
|
-
|
|
358
|
+
neon env pull
|
|
359
359
|
|
|
360
360
|
# Pull a specific branch into a specific file
|
|
361
|
-
|
|
361
|
+
neon env pull --branch preview --file .env.preview
|
|
362
362
|
```
|
|
363
363
|
|
|
364
|
-
If you'd rather not keep env vars on disk, inject them at runtime instead with `neon-env run -- <your dev command>` (from `@neon/env`) or `
|
|
364
|
+
If you'd rather not keep env vars on disk, inject them at runtime instead with `neon-env run -- <your dev command>` (from `@neon/env`) or `neon dev`, and pass `--no-env-pull` to `link` / `checkout`.
|
|
365
365
|
|
|
366
366
|
**Where `.neon` lives**: `link` writes `.neon` into the **current working directory** by default. If an existing `.neon` is found in any parent directory, that file is reused — so commands run from a sub-directory of a linked project still pick up the project's context. To pin the location explicitly, pass `--context-file <path>`.
|
|
367
367
|
|
|
@@ -459,20 +459,20 @@ neon config plan --project-id polished-snowflake-12345678 --output json
|
|
|
459
459
|
neon deploy --branch my-feature --update-existing
|
|
460
460
|
```
|
|
461
461
|
|
|
462
|
-
Function deploys declared under `preview.functions` are bundled by
|
|
462
|
+
Function deploys declared under `preview.functions` are bundled by neon's own esbuild helper and uploaded as part of `apply`, so the policy stays declarative and the packaged CLI never has to embed esbuild's native binary.
|
|
463
463
|
|
|
464
464
|
## Scaffold a project (`bootstrap`)
|
|
465
465
|
|
|
466
|
-
`
|
|
466
|
+
`neon bootstrap` copies a Neon starter template into a new (or current) directory — conceptually like `degit`, but it only pulls from a small set of templates we maintain in the public [`neondatabase/examples`](https://github.com/neondatabase/examples) repo. It requires no Neon login: it just downloads files from GitHub.
|
|
467
467
|
|
|
468
468
|
Pass a target directory (or `.` for the current one). In an interactive terminal you pick the template from a list; in CI / non-interactive contexts pass `--template <id>`.
|
|
469
469
|
|
|
470
470
|
```bash
|
|
471
471
|
# Pick a template interactively and scaffold it into ./my-app
|
|
472
|
-
$
|
|
472
|
+
$ neon bootstrap my-app
|
|
473
473
|
|
|
474
474
|
# Scaffold a specific template into the current directory (no prompts)
|
|
475
|
-
$
|
|
475
|
+
$ neon bootstrap . --template hono
|
|
476
476
|
```
|
|
477
477
|
|
|
478
478
|
The target directory must be empty unless you pass `--force` (a lone `.git` is ignored, so a freshly `git init`ed folder is fine). Symlinks and executable bits in the template are preserved.
|
|
@@ -520,23 +520,23 @@ Global options are supported with any Neon CLI command.
|
|
|
520
520
|
Sets the output format. Supported options are `json`, `yaml`, and `table`. The default is `table`. Table output may be limited. The `json` and `yaml` output formats show all data.
|
|
521
521
|
|
|
522
522
|
```bash
|
|
523
|
-
|
|
523
|
+
neon me --output json
|
|
524
524
|
```
|
|
525
525
|
|
|
526
526
|
- <a id="config-dir"></a>`--config-dir`
|
|
527
527
|
|
|
528
|
-
Specifies the path to the `
|
|
528
|
+
Specifies the path to the `neon` configuration directory. To view the default configuration directory containing you `credentials.json` file, run `neon --help`. The credentials file is created when you authenticate using the `neon auth` command. This option is only necessary if you move your `neon` configuration file to a location other than the default.
|
|
529
529
|
|
|
530
530
|
```bash
|
|
531
|
-
|
|
531
|
+
neon projects list --config-dir /home/dtprice/.config/neonctl
|
|
532
532
|
```
|
|
533
533
|
|
|
534
534
|
- <a id="api-key"></a>`--api-key`
|
|
535
535
|
|
|
536
|
-
Specifies your Neon API key. You can authenticate using a Neon API key when running a Neon CLI command instead of using `
|
|
536
|
+
Specifies your Neon API key. You can authenticate using a Neon API key when running a Neon CLI command instead of using `neon auth`. For information about obtaining an Neon API key, see [Authentication](https://api-docs.neon.tech/reference/authentication), in the _Neon API Reference_.
|
|
537
537
|
|
|
538
538
|
```bash
|
|
539
|
-
|
|
539
|
+
neon <command> --api-key <neon_api_key>
|
|
540
540
|
```
|
|
541
541
|
|
|
542
542
|
- <a id="analytics"></a>`--analytics`
|
|
@@ -548,20 +548,20 @@ Global options are supported with any Neon CLI command.
|
|
|
548
548
|
Shows the Neon CLI version number.
|
|
549
549
|
|
|
550
550
|
```bash
|
|
551
|
-
$
|
|
551
|
+
$ neon --version
|
|
552
552
|
1.15.0
|
|
553
553
|
```
|
|
554
554
|
|
|
555
555
|
- <a id="help"></a>`-h, --help`
|
|
556
556
|
|
|
557
|
-
Shows the `
|
|
557
|
+
Shows the `neon` command-line help. You can view help for `neon`, a `neon` command, or a `neon` subcommand, as shown in the following examples:
|
|
558
558
|
|
|
559
559
|
```bash
|
|
560
|
-
|
|
560
|
+
neon --help
|
|
561
561
|
|
|
562
|
-
|
|
562
|
+
neon branches --help
|
|
563
563
|
|
|
564
|
-
|
|
564
|
+
neon branches create --help
|
|
565
565
|
```
|
|
566
566
|
|
|
567
567
|
## Contribute
|
|
@@ -581,7 +581,7 @@ To develop continuously:
|
|
|
581
581
|
pnpm run watch
|
|
582
582
|
```
|
|
583
583
|
|
|
584
|
-
To run commands from the local build, replace the `
|
|
584
|
+
To run commands from the local build, replace the `neon` command with `node dist`; for example:
|
|
585
585
|
|
|
586
586
|
```shell
|
|
587
587
|
node dist branches --help
|
package/dist/dev/env.js
CHANGED
|
@@ -177,7 +177,7 @@ const isMissingResource = (change) => change.kind === "service" &&
|
|
|
177
177
|
const fetchAndProject = async (config, ctx) => {
|
|
178
178
|
const env = await fetchEnv(config, {
|
|
179
179
|
projectId: ctx.projectId,
|
|
180
|
-
|
|
180
|
+
branch: ctx.branchId,
|
|
181
181
|
...apiOptions(ctx),
|
|
182
182
|
...(ctx.env ? { env: ctx.env } : {}),
|
|
183
183
|
});
|
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "neonctl",
|
|
3
|
-
"version": "2.29.
|
|
3
|
+
"version": "2.29.2",
|
|
4
4
|
"description": "CLI tool for Neon Serverless Postgres",
|
|
5
5
|
"keywords": [
|
|
6
6
|
"neon",
|
|
@@ -31,7 +31,7 @@
|
|
|
31
31
|
"package.json"
|
|
32
32
|
],
|
|
33
33
|
"engines": {
|
|
34
|
-
"node": ">=
|
|
34
|
+
"node": ">=20.18.1"
|
|
35
35
|
},
|
|
36
36
|
"dependencies": {
|
|
37
37
|
"@hono/node-server": "2.0.4",
|
|
@@ -47,14 +47,14 @@
|
|
|
47
47
|
"openid-client": "6.8.1",
|
|
48
48
|
"pg-protocol": "^1.14.0",
|
|
49
49
|
"prompts": "2.4.2",
|
|
50
|
-
"undici": "^
|
|
50
|
+
"undici": "^7.28.0",
|
|
51
51
|
"which": "3.0.1",
|
|
52
52
|
"yaml": "2.4.5",
|
|
53
53
|
"yargs": "17.7.2",
|
|
54
|
-
"@neon/sdk": "0.1.0",
|
|
55
54
|
"@neon/config": "0.8.1",
|
|
56
55
|
"@neon/config-runtime": "0.8.1",
|
|
57
|
-
"@neon/
|
|
56
|
+
"@neon/sdk": "0.1.0",
|
|
57
|
+
"@neon/env": "0.9.0"
|
|
58
58
|
},
|
|
59
59
|
"optionalDependencies": {
|
|
60
60
|
"esbuild": "0.28.0"
|