naro-cli 0.19.0 → 0.19.1

package/README.md

@@ -93,9 +93,12 @@ naro env add DATABASE_URL production
 naro env remove DATABASE_URL       The production, preview and all values; an environment's only with its name
                                    (naro env remove DATABASE_URL qa)
 naro env pull [.env.local]         Preview's values by default; --env production, or --env qa for an environment
-                                   (its own value wins over all; an unknown name fails before anything is written)
+                                   (its own value wins over all; an unknown name fails before anything is written,
+                                   and so does a value no dotenv line reads back)
 naro env import .env.qa qa         Upload every variable in a dotenv file to one target (all by default; asks first,
-                                   --yes in CI; invalid keys or values over 5 KB stop it before any request)
+                                   --yes in CI; an unclosed quote, an invalid key, ASSETS or a value over 5 KB
+                                   stops it before any request, and so does a key a storage binding already uses
+                                   when there are over 100 variables; an empty value is uploaded and shown (empty))
 
 naro environments                  List the project's environments: address, branch, protection, and how many the plan allows
 naro environments create qa --branch qa
@@ -202,6 +205,8 @@ naro storage bucket list | empty <name> | remove <name> [--empty]   (empty and r
 naro storage ls naro://avatars/u1 [--recursive] [--search <text>]   Names that start with <text>, ASCII case ignored
 naro storage cp ./me.png naro://avatars/u1/me.png [--upsert]   Up to the object limit, under 4 GiB (over 50 MiB in parts), with the service key
 naro storage cp naro://docs/team-1/plan.pdf ./                  Replaces a local file of the same name
+naro storage cp naro://docs/a.pdf naro://docs/b.pdf [--upsert]  Inside one bucket, up to 5 GiB − 5 MiB
+naro storage mv naro://docs/a.pdf naro://docs/old/a.pdf         Inside one bucket, up to 5 GiB − 5 MiB; never replaces
 naro storage rm naro://avatars/u1/old.png [--recursive]   (asks first)
 naro storage rm naro://avatars/u1/ --recursive   Everything under u1/; written u1, an object u1 too
 
@@ -326,10 +331,11 @@ four actions; any other new table is closed to the Data API until you give it
 a policy (`CREATE POLICY` in a migration, or `naro policy create` or
 `naro policy set`; the command says so).
 Policies go with their table, as in Postgres and as `naro db push` does it,
-in the same migration: a drop removes the table's policies, and a rename
+in the same migration: a drop removes the table's policies, a rename
 moves them to the new name and rewrites the policies of other tables that
-read it (the command says which). A rename such a policy cannot follow is
-refused before anything runs. A table the command creates, or renames onto a
+read it, and `rename-column` rewrites every policy that reads the column,
+an owner rule's column included (the command says which). A rename such a
+policy cannot follow is refused before anything runs. A table the command creates, or renames onto a
 name, never inherits what an earlier table of that name left there: that is
 removed first. A change that fails changes no policy. Whatever a command
 removes it prints so it can be made again: as `CREATE POLICY` statements, which
@@ -601,6 +607,11 @@ the `CREATE POLICY` statements again after the rename, in the same migration.
 A plain `ALTER TABLE a RENAME TO b` in a migration moves `a`'s policies to `b`,
 and a policy of another table that reads `a` is written to read `b` — do not
 create them again on `b`: a policy of the same name already there is refused.
+`ALTER TABLE t RENAME COLUMN c TO d` writes every policy that reads `t.c` —
+`t`'s own, another table's through a subquery, an owner rule's column — to
+read `t.d`, so each keeps reading the column it read, as in Postgres. A rename
+a policy cannot follow, such as giving a column the name of a dropped one that
+a policy still reads, is refused before anything runs.
 `naro db table`, the table editor and MCP do the same.
 The answer's `warnings` lists the policies a migration removed, with SQL you
 can paste; it also says when the project has no backend yet (the policies are
@@ -826,6 +837,173 @@ An `--update-check` you give replaces the default: without
 
 ## Release notes
 
+### 0.19.1
+
+0.19.0 went out on 2026-10-19 without these.
+
+- `naro git connect` says what to do when the link alone is not enough. The
+  control plane now records, for each team, only the repositories the people
+  who connected GitHub could read themselves (known-issues #232), and for an
+  account the team already holds it hands out an import link
+  (`/api/github/authorize`) rather than an install one. Without a terminal
+  or with `--json` the error reads
+  `Naro cannot reach <owner/repo> yet. Open <url> to give Naro access (if the repository is not among the ones the Naro GitHub App was granted on GitHub, add it there first), then run: naro git connect`
+  (0.19.0: `… Install the Naro GitHub App at <url>, then run: naro git connect`);
+  in a terminal, after `Opening <url>`, it adds
+  `If the repository is not among the ones the Naro GitHub App was granted on GitHub, add it there first.`
+- `deployDirectory`, the library export the MCP server uses, now refuses
+  `production: true` with any `environment` (`""` too):
+  `VALIDATION_FAILED` `environment and production cannot be used together.`,
+  the control plane's own words, before any value is read, asked for or
+  sent and before the deployment is created (the MCP `deploy` tool still
+  signs in and looks the team up first). 0.19.0 sent both and left the
+  refusal to the control plane (a caller passing `onMissingEnv` was asked
+  for missing values first); a control plane from before named
+  environments 1b-2 ignores `environment` and would deploy to production.
+- `naro env remove KEY` with no target, for a key only environments hold,
+  fails `ENV_NOT_FOUND`
+  `No KEY variable found outside named environments. Pass the environment to remove it: qa, staging.`
+  (`--json` details: `key`, `environments`) and still removes nothing. It
+  said `No KEY variable found.`, which a key no row has still gets.
+- `naro env import` refuses more before any request, in this order:
+  `Cannot read <file>.`, `Unclosed quote in <file> at line <n>.`,
+  `No variables found in <file>.`, `Invalid keys in <file>: A-B, 1X.`,
+  `ASSETS is reserved for the project's static files; pick another name.`
+  (the env route's words) or `Values over 5 KB in <file>: BIG.` An empty
+  value (`KEY=`) is uploaded like any other and listed as `(empty)`, so a
+  file `naro env pull` wrote for a project holding one imports back. Past
+  100 variables, and after you say yes, it reads the project's binding
+  names once (its storage bindings, `ASSETS`, and `DB` on a project with
+  the managed database) and fails `VALIDATION_FAILED`
+  `<KEY> is already used by a storage binding.` for the first key of the
+  file that is one, before the first request; the route refuses such a
+  key per request, which left the batches before it saved. Up to 100
+  variables ask nothing: one request is atomic on the server. Any other
+  refusal of a later request (a role, a race) still leaves the earlier
+  ones saved.
+- Dotenv files are read the way Next.js reads them (dotenv 16, what
+  `next dev` runs), for `naro env import` and for the values `naro deploy`
+  reads from `.env.local` once you agree, so the value saved is the one
+  your app saw locally. A value in `'`, `"` or `` ` `` runs to its closing
+  quote over several lines (a PEM key, as `.env.local` for Next.js often
+  holds one). Inside double quotes `\n` and `\r` are a line break and a
+  carriage return and every other backslash stays as written (`\\` is two,
+  `\"` a backslash and a quote); single quotes and backticks are read as
+  written. An unquoted value ends at its first `#` (`abc#def` is `abc`).
+  CRLF ends a line, inside quotes too. A quote that never closes stays in
+  the value, as Next.js reads it (`naro env import` refuses the file). Unlike
+  Next.js, `$VAR` and `${VAR}` are not expanded: a value built from another
+  variable is saved as written. Before, a multi-line value was cut to its
+  first line, opening quote included, and a base64 line ending in `=`
+  became a key of its own.
+- `naro env pull` writes each value so that dotenv and `naro env import`
+  read it back as it was (known-issues #224): bare when nothing in it needs
+  quoting, else in single quotes, in backticks when it holds `'`, or in
+  double quotes when it holds `'` and `` ` ``. A value with a carriage
+  return is written in double quotes with the carriage return as `\r`
+  (dotenv reads a carriage return written as is for a line break). A value
+  ending in a backslash is written bare. Next.js reads every value back as
+  it was except those with a `$`: it expands `$NAME` and `${NAME}`
+  (dotenv-expand) whatever the quotes, so a bcrypt hash `$2b$10$…` is cut
+  down (to `""`, or to what follows its first `.` or `/`) and `pa$$word` is
+  `pa$` for `next dev`, while `naro env import` reads them
+  unchanged. A value no dotenv line reads back fails before the overwrite
+  question and before anything is written, with `VALIDATION_FAILED`
+  ``Cannot write KEY1, KEY2 to a dotenv file: their values hold ', " and ` together.``
+  or, for the rarer carriage return beside `"`, backslash at the end, or
+  written-out `\n` beside `'` and `` ` ``,
+  `Cannot write KEY to a dotenv file: dotenv would not read their values back unchanged.`
+  followed by how to store such a value: without carriage returns or one of
+  the quote characters (a service-account JSON from a CRLF file:
+  `tr -d '\r' < sa.json | naro env add KEY`), or read it with
+  `naro env list --reveal` (`--json` details: `keys`). Before, it wrote such
+  values in double quotes with `\` and `"` escaped, which Next.js reads with
+  the backslashes: pull a file an earlier version wrote
+  again.
+- On a backend from before named policies, renaming a column answers
+  `409 BACKEND_OUTDATED` until `naro backend enable` runs, as creating,
+  dropping or renaming a table does — through `naro db table`,
+  `naro db push` and `naro db query` alike.
+- `naro db table rename-column`, and `ALTER TABLE … RENAME COLUMN` in
+  `naro db push` and `naro db query`, rewrite the Data API policies that read
+  the column, an owner rule's column included (known-issues #90): the
+  command prints
+  `⚠ Rewrote 1 policy that read members.user_id to read members.uid: docs.team.`.
+  Before, a policy reading the old name answered `500 POLICY_INVALID`, and
+  two columns swapped in one change left it reading the other column. The
+  warning that told you to run `naro policy set <table> --owner <new>` is
+  gone. A rename a policy cannot follow is refused before anything runs.
+- `naro db push` and `naro db reset` check a migration's `ALTER TABLE …
+RENAME` the way the control plane now reads it: a column rename whose
+  names cannot be read (`ALTER TABLE t RENAME COLUMN c TO` with nothing
+  after it, `t.c` for the column) is
+  `Statement <i> of <n>: the column name could not be read.` before anything
+  runs. Before, it reached D1 and failed as SQLite's syntax error.
+- `naro storage mv naro://<bucket>/<from> naro://<bucket>/<to>` moves an
+  object inside its bucket, and `naro storage cp` between two `naro://`
+  paths of one bucket copies one there (Storage 3-1i), each up to
+  5 GiB − 5 MiB. Over that the backend answers `413 OBJECT_TOO_LARGE`:
+  `Objects over 5,363,466,240 bytes (5 GiB − 5 MiB) cannot be copied or moved.`
+  A destination ending in `/`, or the bucket alone (`naro://docs`), takes the
+  object's name. `mv` never replaces an
+  object — a name that is taken answers `409 OBJECT_EXISTS`
+  `Object <path> already exists in bucket <bucket>. A move never replaces an object: remove it or choose another name.`
+  — and takes no `--upsert`, `--content-type` or `--cache-control`; `cp`
+  replaces one with `--upsert` and keeps the type and cache-control
+  (`--content-type` and `--cache-control` are refused).
+  Both refuse two buckets before any request:
+  `naro storage cp and mv work inside one bucket: both sides must be in naro://<bucket>.`
+  A name an upload or a download would refuse is refused before any request,
+  in the same words (`INVALID_PATH`
+  `The object path is not valid: it has an empty segment (//).`), and
+  `--recursive` is refused rather than dropped:
+  `naro storage mv takes no --recursive: it moves one object, naro://<bucket>/<path>. --recursive is for naro storage ls and rm.`
+  (`cp` between two `naro://` paths:
+  `A copy inside Storage takes no --recursive: it copies one object, naro://<bucket>/<path>. --recursive is for naro storage ls and rm.`).
+  A project backend from before this release answers them with
+  `BACKEND_OUTDATED`:
+  ``The project backend is older than this Storage command. Run `naro backend enable` to update it, then try again.``
+  `cp` between two `naro://` paths used to answer
+  `Copying inside Storage is not supported yet.` `--json` of a copy carries
+  `object` (`{ id, path, fullPath }`).
+- `naro db lint` measures a `storage.objects` move too (Storage 3-1i): a
+  move binds its new name at every read of the UPDATE policy's check, so a
+  set whose UPDATE check reads `name` many times can now be refused before
+  it is pushed, though an overwrite under it fits; the backend would answer
+  every move `500 POLICY_INVALID`. A copy's claim is an upload's and changes
+  nothing.
+- A table's policy can read `storage.objects` in a subquery (Storage 3-1j),
+  and so can a `realtime.messages` policy. `naro db push --dry-run`,
+  `naro db reset` and `naro policy create` take such a policy here, where
+  0.18.0 and 0.19.0 refused it locally, before changing anything, with
+  `A policy cannot read storage.objects in a subquery yet at character <n>.`,
+  and `naro db lint` no longer reports a stored one as `rls_policy_invalid`
+  (known-issues #227). `naro db reset` lists a stored one your files do not
+  make with the SQL that keeps it, where 0.18.0 and 0.19.0 showed
+  `-- Policy <p> on <t> cannot be read (…)` in its place (in `--json` too)
+  and, once confirmed, dropped it with no SQL to make it again. The backend reads it through the caller's
+  `storage.objects` policies and only files that are fully there (not still
+  uploading or being removed); write `bucket_id = '<bucket>'` in the
+  subquery (`bucket_id in ('a', 'b')` for several buckets). A check never
+  finds a new file being uploaded or copied, or a move's new name, as in
+  Postgres. A backend
+  from before Storage 3-1j answers such a policy with
+  `409 BACKEND_OUTDATED`:
+  ``storage.objects is not available on this backend yet. Run `naro backend enable` to update it.``
+  `naro db lint` measures those policies inside the table's statement, and
+  for a signed-in caller whose email is not verified too.
+- `naro db reset` refuses, before it drops anything (and on `--dry-run`
+  too), migration files the backend would stop at for Storage: a policy that
+  reads `storage.objects` in a subquery while the backend's ledger lacks
+  system migration 7 (it reads the ledger only when a file has one), and
+  any statement on `storage.objects` (CREATE POLICY, DROP POLICY without
+  IF EXISTS, the `naro:owner` COMMENT) on a backend from before Storage or a
+  project with none. It fails `BACKEND_OUTDATED`
+  ``0002_b.sql needs storage.objects (statement 2 of 2), which is not available on this backend yet, so the reset would stop there with the schema already dropped. Nothing was changed. Run `naro backend enable` to update it, then try again.``
+  (`--json` details: `migration`, `statement`). Before, the checks passed,
+  the schema was dropped and the re-apply stopped at the control plane's
+  `409 BACKEND_OUTDATED`, with `The schema is dropped and the re-apply stopped.`
+
 ### 0.19.0
 
 - `naro environments` manages a project's named environments, QA or staging
@@ -905,9 +1083,10 @@ An `--update-check` you give replaces the default: without
   deploy gets. A production deploy now lists a key set only for preview as
   missing, and a preview deploy one set only for production; an environment
   deploy counts the `all` values and that environment's own. On an
-  environment deploy, the values typed at the env prompt are saved for that
-  environment alone, so a developer, who cannot change `all`, has them saved
-  instead of listed under `⚠ skipped env:`. Production and preview deploys
+  environment deploy, the values the deploy reads from your dotenv file
+  (once you agree to it) are saved for that environment alone, so a
+  developer, who cannot change `all`, has them saved instead of listed under
+  `⚠ skipped env:`. Production and preview deploys
   still save them for `all`. The hint names the environment too:
   `npx naro-cli env add DATABASE_URL qa`.
 - `naro env add` and `naro env remove` take an environment's slug as the
@@ -948,6 +1127,11 @@ An `--update-check` you give replaces the default: without
   reads as `KEY`. Values with `\"` or `\\` inside double quotes are read as
   written, not unescaped, so a file `naro env pull` wrote with such a value
   does not import back as it was (known-issues #224).
+  A value in quotes that runs over several lines (a PEM key) is cut to
+  its first line, opening quote included, and a base64 line ending in
+  `=` becomes a key of its own, though the result says `✅ Imported`.
+  The values `naro deploy` reads from `.env.local` once you agree are cut
+  the same way, with no warning. Use 0.19.1 for such a file.
 - `naro env add` with a value typed at the prompt no longer loses it to a
   refusal. It reads the project first, so a `--project` of another team or
   of a deleted project fails `404 NOT_FOUND "Project not found."` before the
@@ -962,6 +1146,9 @@ An `--update-check` you give replaces the default: without
   another. A piped value works as before.
 - `naro usage` names a project that has moved to another team
   `Moved to another team <id>`. Before, it read `Deleted project <id>`.
+- `naro usage` prints `<1%` for a meter that is used but under 1% of its
+  limit (9,056 of 1,000,000 requests). Before, it printed `0%`, as if
+  nothing had been used.
 - `naro db reset` reads the migration files the way the control plane now
   runs them: `ALTER TABLE a RENAME TO b` moves `a`'s policies to `b`
   (known-issues #87), so a policy a renamed table took along is no longer
@@ -1405,5 +1592,5 @@ credentials live in `~/.naro/credentials.json` (0600).
 | ------------------------ | ---------------------------------------------- |
 | `NARO_TOKEN`             | CI/agent access token (skips `naro login`)     |
 | `NARO_CONTROL_PLANE_URL` | Custom control plane (default https://naro.sh) |
-| `NARO_SERVICE_KEY`       | Service key for `naro storage ls\|cp\|rm`      |
+| `NARO_SERVICE_KEY`       | Service key for `naro storage ls\|cp\|mv\|rm`  |
 | `NARO_SUPABASE_URL/KEY`  | Auth backend override (self-hosted setups)     |