naro-cli 0.15.0 → 0.17.0

package/README.md

@@ -88,7 +88,8 @@ naro env remove DATABASE_URL
 naro env pull [.env.local]
 
 naro domains list
-naro domains add www.example.com   Prints the DNS records to create
+naro domains add www.example.com   Prints the CNAME to create; naro connects
+                                   it within ~5 minutes of the record appearing
 naro domains add example.com       Apex: also connects www.example.com and
                                    redirects the apex to it (--no-www to skip)
 naro domains verify [host]         Re-check DNS now and print what is missing
@@ -180,7 +181,7 @@ naro storage bucket update avatars --private | --file-size-limit none | --allowe
 naro storage bucket update docs --public   (asks first: anyone with an object's URL can download it)
 naro storage bucket list | empty <name> | remove <name> [--empty]   (empty and remove ask first)
 naro storage ls naro://avatars/u1 [--recursive]
-naro storage cp ./me.png naro://avatars/u1/me.png [--upsert]   Up to 50 MiB, with the service key
+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 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
@@ -190,8 +191,9 @@ naro rollback [deployment-id]      Back to the previous production build
 ```
 
 `naro domains list` reads the stored status; `naro domains verify` is the one
-that asks Cloudflare and the DNS again, so it is what turns a stuck "pending"
-into the reason it is stuck. It exits non-zero while a domain is not live —
+that asks the DNS and Cloudflare again — and registers the domain on the spot
+once its CNAME points at naro — so it is what turns a stuck "pending" into the
+reason it is stuck. It exits non-zero while a domain is not live —
 with or without `--wait` — so CI can gate on it:
 
 ```bash
@@ -203,6 +205,15 @@ An apex (`example.com`) is added as a pair by default because most registrars
 goes on `www.example.com` and the apex answers with a 308 redirect to it.
 `--no-www` registers the apex alone.
 
+A domain another naro project already has is not refused. `naro domains add`
+fails with `DOMAIN_VERIFICATION_REQUIRED`, and the message names a TXT record:
+`_naro-verify.<host>` with the value `naro-verify=<token>`. Create it, then run
+`naro domains verify <host>`. Once the record is visible, the domain moves to
+this project. After that, the CNAME is added as usual. Add the TXT record
+before the CNAME: until the move, the other project still serves the domain.
+The check lasts 7 days. `naro domains list` shows open checks with their
+expiry, and adding the domain again prints the same token.
+
 `naro db dump` asks Cloudflare for the dump and streams it straight from
 Cloudflare's storage to the file — the bytes never pass through naro. While the
 export runs, Cloudflare holds every other query to the database, so dump a busy
@@ -793,13 +804,64 @@ An `--update-check` you give replaces the default: without
 
 ## Release notes
 
+### 0.17.0
+
+- `naro domains add` prints one CNAME record and no TXT records. naro
+  registers the domain once the CNAME points at it, usually within about five
+  minutes. The status line reads `Waiting for DNS — add the CNAME above; naro
+connects it within about five minutes.` `naro domains verify` registers it at
+  once.
+- A domain another project holds now gets an ownership check instead of
+  `DOMAIN_EXISTS` (see the `naro domains` notes under Commands). `naro domains verify <host>`
+  reads the TXT record and moves the domain here. `naro domains list` shows
+  open checks under `Ownership checks (n):`. Against a control plane that
+  predates ownership checks, list shows none.
+- A control plane without custom domains set up answers domain changes with
+  `503 DOMAINS_NOT_CONFIGURED` (`Custom domains are not configured on this
+server.`), and the CLI prints that message. Before, the CLI got a 500.
+- `naro deploy` builds Next.js apps that use npm faster:
+  - A second build candidate copies the installed packages instead of
+    installing them again.
+  - npm's audit and funding notices are off during the build. A project
+    `.npmrc` that turns audit on still wins.
+
+### 0.16.0
+
+- `naro storage cp` uploads a file up to the object limit, under 4 GiB. Over
+  50 MiB it goes in parts, four at a time, and a part that fails is sent again
+  (up to three more times) before the upload stops. The 50 MiB refusal before
+  any request is gone: the worker judges the size when the upload starts, and a
+  file over the bucket's or the plan's limit answers `413 OBJECT_TOO_LARGE`
+  before a byte is sent. An upload in parts must finish within 24 hours of its
+  start (R2 ends unfinished multipart uploads after a day). A big upload prints its progress on stderr: one line
+  rewritten in place at a terminal, a line every 10% otherwise
+  (`↑ 312 MiB / 1.2 GiB (26%)`), and nothing with `--json`.
+- Ctrl-C during an upload (or a TERM, or the terminal closing) stops it:
+  `Stopping the upload…` on stderr, the upload is called off — one in parts on
+  the backend too, so its name and the space it reserved are free at once
+  rather than locked for about an hour — and the run ends with the signal. A
+  second Ctrl-C ends it at once, without waiting for the call-off. A process
+  killed outright, or a network lost, still leaves the name locked until the
+  lock runs out.
+- A file of 4 GiB or more is refused before any request
+  (`VALIDATION_FAILED`): Node reads its size modulo 4 GiB (4 GiB + 1 KiB reads
+  as 1 KiB), and the upload would send only that much and report success.
+  Uploading one needs a change in naro-js that is not there yet.
+- A download is written to disk as it arrives, to a hidden `.naro-partial`
+  file that replaces the destination once it is whole, instead of being held in
+  memory first.
+- `naro storage` says `50 MiB per request (larger files go in parts)`, and
+  that uploads stopped over the storage limit reopen usually within an hour and
+  a half: R2 reports the bucket's size 30 minutes to about an hour and a half
+  late.
+
 ### 0.15.0
 
 - `naro storage` shows the Storage meter's day between `Used:` and `Buckets:`:
   `Today (UTC):` has the write operations (R2 Class A) against the daily limit
   and the reads, `Measured:` the bucket size R2 reported and when R2 measured
-  it (R2 reports the size 30–45 minutes late, and the meter reads it every 15
-  minutes). A `✗` line
+  it (R2 reports the size 30 minutes to about an hour and a half late, and the
+  meter reads it every 15 minutes). A `✗` line
   says uploads are stopped, over the storage limit until objects are deleted
   or over the day's write operations until 00:00 UTC (downloads still work);
   a `⚠` line warns from 80% of the storage limit or of the day's write
@@ -872,7 +934,8 @@ An `--update-check` you give replaces the default: without
   (public or private, the largest file, the types taken), and `ls`, `cp`
   and `rm` work on `naro://<bucket>/<path>` with the project's service key
   (`NARO_SERVICE_KEY`, or fetched with a warning) — the bytes go to the
-  project's backend, not through naro. One upload is 50 MiB at most.
+  project's backend, not through naro. One request carries 50 MiB at most; a
+  larger file goes in parts since 0.16.0 (under 4 GiB).
   `bucket update --public`, `empty`, `remove` and `rm` ask first; without a
   terminal they need `--yes` (`CONFIRMATION_REQUIRED` otherwise, nothing
   sent).