@cbortech/cbor 0.26.8 → 0.27.1

package/README.md

@@ -392,19 +392,23 @@ CBOR.format("h'68' + b64'aQ'", {
 //   b64'aQ'
 ```
 
-### Preserve application-string/-sequence notation
+To render the preserved concatenation using draft-27's `t1<<...>>` /
+`b1<<...>>` notation instead of `+`, see `modernConcat` in
+[String Concatenation and Indefinite-Length Strings](#string-concatenation-and-indefinite-length-strings).
+
+### Preserve app-string/-sequence notation
 
 Some built-in extensions (`dt`/`DT`, `ip`/`IP`) support `prefix'...'`
-(application string), `` prefix`...` `` (backtick application string),
-`prefix<<...>>` (application sequence), and a raw tag literal (`N(...)`)
+(app-string), `` prefix`...` `` (backtick app-string),
+`prefix<<...>>` (app-sequence), and a raw tag literal (`N(...)`)
 notation for the same value, and by default regenerate `prefix'...'` from
 the resolved value on every `CBOR.format()` call — so
 `` DT`1969-07-21T02:56:16Z` ``, `DT<<'1969-07-21T02:56:16Z'>>`, and even the
 raw tag form `1(1749772800)` all normalize to `DT'...'` notation, and a
 non-canonical `DT'...'` spelling (e.g. a `+00:00` offset instead of `Z`)
-gets rewritten too. `preserveAppSequence` keeps the original spelling
+gets rewritten too. `preserveAppPrefix` keeps the original spelling
 instead — whichever form was used. It has no effect when
-`appStrings: false` is also set (raw tag notation is used either way
+`appPrefix: false` is also set (raw tag notation is used either way
 regardless of the original spelling), or on values not parsed from one of
 these forms.
 
@@ -414,16 +418,50 @@ import { CBOR } from '@cbortech/cbor';
 CBOR.format('1(1749772800)');
 // "DT'2025-06-13T00:00:00Z'"
 
-CBOR.format('1(1749772800)', { preserveAppSequence: true });
+CBOR.format('1(1749772800)', { preserveAppPrefix: true });
 // "1(1749772800)"
 
-CBOR.format("DT<<'1969-07-21T02:56:16Z'>>", { preserveAppSequence: true });
+CBOR.format("DT<<'1969-07-21T02:56:16Z'>>", { preserveAppPrefix: true });
 // "DT<<'1969-07-21T02:56:16Z'>>"
 
-CBOR.format('DT`1969-07-21T02:56:16Z`', { preserveAppSequence: true });
+CBOR.format('DT`1969-07-21T02:56:16Z`', { preserveAppPrefix: true });
 // "DT`1969-07-21T02:56:16Z`"
 ```
 
+### Preserve comments
+
+By default, `CBOR.fromCDN()` discards comments and `CBOR.format()` emits
+none. `preserveComments: true` captures them while parsing and re-emits each
+comment verbatim, with whichever marker (`#`, `//`, `/* */`, `/ /`) it was
+originally written with.
+
+```ts
+import { CBOR } from '@cbortech/cbor';
+
+const text = '{ "a": 1 } # trailing comment';
+
+CBOR.format(text, { indent: 2 });
+// '{\n  "a": 1\n}'
+
+CBOR.format(text, { indent: 2, preserveComments: true });
+// '{\n  "a": 1\n} # trailing comment'
+```
+
+To normalize every comment's marker instead of keeping the mix as originally
+written, use `comments` — `'c-style'` for `//` and `/* */`, or
+`'cdn-style'` for `#` and `/ /`. It has no effect when `preserveComments` is
+`true` (verbatim wins); explicitly set `comments: 'strip'` (or leave
+both options unset) to drop comments entirely.
+
+```ts
+CBOR.format(text, { indent: 2, comments: 'c-style' });
+// '{\n  "a": 1\n} // trailing comment'
+```
+
+Only effective when `indent` enables pretty-printing: single-line output
+strips all comments regardless, since line comments can only be terminated
+by a newline.
+
 ### Preserve blank lines
 
 By default, `CBOR.format()` drops blank lines between array/map entries (and
@@ -681,10 +719,85 @@ console.log(text);
 // DT'2026-05-06T00:00:00Z'
 ```
 
+### Per-item option overrides
+
+`itemOptions` on `toJS()` is called for every node before it is converted, so
+one part of a document can be converted differently from the rest. Return a
+partial options object to override options for that node and its descendants,
+or `undefined` to leave them unchanged. `ctx.path` identifies the node as a
+sequence of array indices and map keys, empty at the root.
+
+It can be called more than once for the same node — when a `reviver` is also
+present, arrays and object-mode maps convert each child at least twice: once
+to build a value visible to an earlier sibling's own `reviver` call, and once
+more for the value that's actually kept. Write it as a pure function of
+`node`/`ctx`, not relying on how many times it runs.
+
+```ts
+import { CBOR } from '@cbortech/cbor';
+
+const item = CBOR.fromCDN(
+  `{"date1": DT'2026-08-23T00:00:00Z', "date2": DT'2026-08-23T00:00:00Z'}`
+);
+
+const value = item.toJS({
+  stripTags: true,
+  itemOptions: (_node, ctx) =>
+    ctx.path.length === 1 && ctx.path[0] === 'date1'
+      ? { extensions: [CBOR.dt_as_Date] }
+      : undefined,
+});
+
+console.log(value);
+// { date1: Date(...), date2: 1787443200 }
+```
+
+`extensions` on `ToJSOptions` also works on its own, without `itemOptions`, to
+reinterpret an entire tree: a value parsed with the default `dt` extension can
+still be converted with `dt_as_Date` (or vice versa) by passing `extensions`
+directly to `toJS()`.
+
+`ctx.options` carries the options already in effect for the node — the root
+options merged with whatever an ancestor's `itemOptions` already returned —
+so a callback can build on the current value of an option instead of
+overriding it outright:
+
+```ts
+itemOptions: (_node, ctx) => ({
+  extensions: [...(ctx.options.extensions ?? []), CBOR.dt_as_Date],
+});
+```
+
+`toCDN()` takes the same `itemOptions` option, formatting one part of a
+document differently from the rest:
+
+```ts
+import { CBOR } from '@cbortech/cbor';
+
+const item = CBOR.fromCDN('{"raw": 255, "count": 255}');
+
+const text = item.toCDN({
+  itemOptions: (_node, ctx) =>
+    ctx.path.length === 1 && ctx.path[0] === 'raw'
+      ? { intFormat: 'hex' }
+      : undefined,
+});
+
+console.log(text);
+// {"raw":0xff,"count":255}
+```
+
+There is no `reviver` for `toCDN()`, so it can't be called more than once for
+that reason — but it can still be called more than once for a node that's
+also a `toCDN()` layout decision (`inlineLeafContainers`'s one-line collapse
+check, or a tag/app-sequence value's own multi-word check re-render an entry
+purely to answer that question before the real render). Write it as a pure
+function here too.
+
 ## String Concatenation and Indefinite-Length Strings
 
-The `t1` / `b1` / `ilbs` / `ilts` application extensions from
-draft-ietf-cbor-edn-literals-26 (§3.4 / §3.5) are enabled by default.
+The `t1` / `b1` / `ilbs` / `ilts` app-extensions from
+draft-ietf-cbor-edn-literals-27 (§3.5 / §3.6) are enabled by default.
 
 `t1<<...>>` and `b1<<...>>` join (text or byte) string arguments from left to
 right into a single text string (`t1`) or byte string (`b1`). Arguments may
@@ -694,11 +807,11 @@ also be ellipses (`...`) to elide parts of a string.
 import { CBOR } from '@cbortech/cbor';
 
 const text = CBOR.fromCDN('t1<<"Hello ", "world">>');
-console.log(text.toCDN({ appStrings: false }));
+console.log(text.toCDN({ appPrefix: false }));
 // "Hello world"
 
 const bytes = CBOR.fromCDN("b1<<'Hello ', h'776f726c64'>>");
-console.log(bytes.toCDN({ appStrings: false }));
+console.log(bytes.toCDN({ appPrefix: false }));
 // 'Hello world'
 ```
 
@@ -711,29 +824,81 @@ documents; this library keeps accepting the legacy syntax on input.
 import { CBOR } from '@cbortech/cbor';
 
 const v = CBOR.fromCDN("ilbs<<'Hello ', 'world'>>");
-console.log(v.toCDN({ appStrings: false }));
+console.log(v.toCDN({ appPrefix: false }));
 // (_ 'Hello ','world')
 ```
 
+### Emitting `t1`/`b1`/`ilbs`/`ilts` notation
+
+Parsing already accepts `t1`/`b1`/`ilbs`/`ilts` notation, but by default
+`toCDN()`/`CBOR.format()` never emit it on their own: a preserved
+concatenation (`preserveConcatenation`) still renders as `+`, and an
+indefinite-length string still renders as the legacy `(_ ...)` streamstring
+form. `modernConcat` and `modernStreamSyntax` opt into emitting the draft-27
+notation instead — both default to `false` (the legacy syntax), and both fall
+back to it when `appPrefix` is `false`.
+
+```ts
+import { CBOR } from '@cbortech/cbor';
+
+CBOR.format('"a" + "b"', {
+  indent: 2,
+  preserveConcatenation: true,
+  modernConcat: true,
+});
+// t1<<"a", "b">>
+
+CBOR.format('(_ "a", "b")', { modernStreamSyntax: true });
+// ilts<<"a","b">>
+```
+
+`modernConcat` also applies within a `...` elision chain (§5.2), rendering
+`"a" + ... + "b"` as `t1<<"a", ..., "b">>` — unlike plain concatenation, this
+happens regardless of `preserveConcatenation`, since an elision chain has no
+single-literal collapsed form to fall back to in the first place.
+
+> [!NOTE]
+> Neither option converts `t1`/`b1`/`ilbs`/`ilts` source back to the
+> legacy notation: a value parsed from `t1<<...>>` (or `ilbs<<...>>`, etc.)
+> keeps that exact spelling on output regardless of `modernConcat` /
+> `modernStreamSyntax` — as long as `appPrefix` is not `false`,
+> `encodingIndicators` is `'auto'` (both defaults), and the source is either
+> single-line or being rendered with `indent` enabled. `encodingIndicators:
+'always'`/`'never'` or `appPrefix: false` still normalize it like any
+> other app-string value (e.g. `t1<<"a", "b">>` becomes `"ab"_i`
+> under `encodingIndicators: 'always'`), and a multi-line source falls back
+> to normalized output in single-line mode (that layout can't be reproduced
+> without `indent`):
+>
+> ```ts
+> CBOR.format('t1<<\n  "a",\n  "b"\n>>');
+> // '"ab"' — falls back: multi-line source, no `indent`
+> CBOR.format('t1<<\n  "a",\n  "b"\n>>', { indent: 2 });
+> // 't1<<\n  "a",\n  "b"\n>>' — kept verbatim
+> ```
+>
+> Both options only affect how a value reconstructed from a `+` chain or a
+> `(_ ...)` chunk list is _newly_ rendered.
+
 > [!NOTE]
-> The identifiers `t1` and `b1` are explicitly provisional in draft-26 and
+> The identifiers `t1` and `b1` are explicitly provisional in draft-27 and
 > may be renamed by the CBOR working group.
 
 ## float
 
 Interprets a hex bit-pattern as an IEEE 754 floating-point value
-(draft-ietf-cbor-edn-literals-26 §3.7). Enabled by default.
+(draft-ietf-cbor-edn-literals-27 §3.8). Enabled by default.
 
 ```ts
 import { CBOR } from '@cbortech/cbor';
 
 const v = CBOR.fromCDN("float'7e00'");
-console.log(v.toCDN({ appStrings: false }));
+console.log(v.toCDN({ appPrefix: false }));
 // NaN
 
 // Interpret bytes as float bits
 const v2 = CBOR.fromCDN("float<<h'3f800000'>>");
-console.log(v2.toCDN({ appStrings: false }));
+console.log(v2.toCDN({ appPrefix: false }));
 // 1.0_2
 ```
 
@@ -747,7 +912,7 @@ default. Import what you need and pass it through the `extensions` option.
 Byte-string literals using [RFC 4648](https://www.rfc-editor.org/rfc/rfc4648)
 Base32 encoding. These prefixes are described in §8 of
 [RFC 8949](https://www.rfc-editor.org/rfc/rfc8949) and also mentioned in
-[draft-ietf-cbor-edn-literals](https://datatracker.ietf.org/doc/draft-ietf-cbor-edn-literals/25/).
+[draft-ietf-cbor-edn-literals](https://datatracker.ietf.org/doc/draft-ietf-cbor-edn-literals/27/).
 
 - `b32` — §6 Base32 (`A–Z 2–7` alphabet)
 - `h32` — §7 Base32Hex (`0–9 A–V` alphabet)
@@ -756,11 +921,11 @@ Base32 encoding. These prefixes are described in §8 of
 import { CBOR, b32, h32 } from '@cbortech/cbor';
 
 const v1 = CBOR.fromCDN("b32'AEBAGBA'", { extensions: [b32] });
-console.log(v1.toCDN({ appStrings: false }));
+console.log(v1.toCDN({ appPrefix: false }));
 // h'01020304'
 
 const v2 = CBOR.fromCDN("h32'00P00'", { extensions: [h32] });
-console.log(v2.toCDN({ appStrings: false }));
+console.log(v2.toCDN({ appPrefix: false }));
 // h'003200'
 ```
 
@@ -774,24 +939,24 @@ identical CBOR bytes and returns the first item. This extension is described in
 import { CBOR, same } from '@cbortech/cbor';
 
 const v = CBOR.fromCDN("same<<h'0102', h'0102'>>", { extensions: [same] });
-console.log(v.toCDN({ appStrings: false }));
+console.log(v.toCDN({ appPrefix: false }));
 // h'0102'
 
 // A single-item sequence always passes
 const v2 = CBOR.fromCDN('same<<42>>', { extensions: [same] });
-console.log(v2.toCDN({ appStrings: false }));
+console.log(v2.toCDN({ appPrefix: false }));
 // 42
 ```
 
 ---
 
-Additional application extensions are published as separate packages. Install
+Additional app-extensions are published as separate packages. Install
 the ones you need and pass them through the `extensions` option.
 
 ### hash
 
-`hash` is an application extension defined in §3.3 of
-[draft-ietf-cbor-edn-literals](https://datatracker.ietf.org/doc/draft-ietf-cbor-edn-literals/25/).
+`hash` is an app-extension defined in §3.4 of
+[draft-ietf-cbor-edn-literals](https://datatracker.ietf.org/doc/draft-ietf-cbor-edn-literals/27/).
 It represents cryptographic hash values in the form `hash'algorithm:value'`.
 Because it requires an external cryptographic library, it is provided separately
 as [@cbortech/hash-extension](https://www.npmjs.com/package/@cbortech/hash-extension).
@@ -816,7 +981,7 @@ const digest = cbor.parse(
 
 ### uuid
 
-`uuid` is a library-specific application extension, provided separately as
+`uuid` is a library-specific app-extension, provided separately as
 [@cbortech/uuid-extension](https://www.npmjs.com/package/@cbortech/uuid-extension).
 
 ```bash
@@ -835,7 +1000,7 @@ const id = cbor.parse("uuid'550e8400-e29b-41d4-a716-446655440000'");
 
 ### set / map
 
-`SET` and `MAP` are library-specific application extensions for tagged Set and
+`SET` and `MAP` are library-specific app-extensions for tagged Set and
 Map values. They are provided together as
 [@cbortech/set-map-extensions](https://www.npmjs.com/package/@cbortech/set-map-extensions).
 `SET<<[...]>>` produces CBOR tag 258 over an array, and `MAP<<{...}>>` produces
@@ -1093,9 +1258,11 @@ types).
 
 - CBOR
   - [RFC 8949](https://www.rfc-editor.org/rfc/rfc8949)
+- CBOR Sequences
+  - [RFC 8742](https://www.rfc-editor.org/rfc/rfc8742)
 - CDN (CBOR-EDN)
   - [draft-ietf-cbor-edn-literals-25](https://datatracker.ietf.org/doc/draft-ietf-cbor-edn-literals/25/)
-  - [draft-ietf-cbor-edn-literals-26](https://datatracker.ietf.org/doc/draft-ietf-cbor-edn-literals/26/)
+  - [draft-ietf-cbor-edn-literals-27](https://datatracker.ietf.org/doc/draft-ietf-cbor-edn-literals/27/)
 - CDDL
   - [RFC 8610](https://www.rfc-editor.org/rfc/rfc8610)
   - [RFC 9682](https://www.rfc-editor.org/rfc/rfc9682)
@@ -1103,7 +1270,7 @@ types).
 
 Implementation notes:
 
-- CDN follows draft-26 while retaining draft-25's `(_ ...)` streamstring syntax
+- CDN follows draft-27 while retaining draft-25's `(_ ...)` streamstring syntax
   and `+` string-concatenation syntax.
 - CDDL implements every RFC 8610 control operator, plus RFC 9165's `.plus`,
   `.cat`, and `.feature`.

package/dist/ast/CborAppSeqResult.d.ts

@@ -1,5 +1,5 @@
 import { ToCDNOptions, ToCBOROptions, ToJSOptions } from '../types';
-import { CborItem } from './CborItem';
+import { CborItem, Occurrence } from './CborItem';
 import { CborWriter } from '../cbor/encode';
 /**
  * Wraps a resolved app-sequence result and preserves the original EDN source
@@ -13,6 +13,39 @@ import { CborWriter } from '../cbor/encode';
  * lines also delegates to the inner item, since it cannot be re-emitted
  * without breaking the single-line guarantee.
  *
+ * When `toCDN()`'s `itemOptions` is configured (see `needsCdnItemDispatch`),
+ * the verbatim `ednSource` fast path alone can't be trusted: it was produced
+ * without ever visiting `this.inner`'s own descendants, so an override
+ * targeting one of them (e.g. one chunk of an `ilbs<<...>>`) would otherwise
+ * never even be offered the chance to apply. But merely *having* `itemOptions`
+ * configured must not by itself change the output — many callers set it
+ * without it ever matching anything in this particular subtree, and
+ * `itemOptions` returning `undefined` everywhere is documented to mean "no
+ * change" (see `CdnItemContext`). So this renders through the normal
+ * recursive path while tracking, via `CDN_OVERRIDE_TRACKER` (an out-of-band
+ * symbol key, *not* a wrapped `itemOptions` — wrapping it would make
+ * `ctx.options.itemOptions` a different function for every descendant here
+ * than everywhere else in the tree, observable even to a pure callback),
+ * whether any call in the subtree actually returned an override, and only
+ * swaps in that freshly rendered text when one did; otherwise the exact
+ * preserved `ednSource` is still returned.
+ *
+ * Each `_toCDN()` call installs its *own fresh* tracker box before
+ * recursing, rather than reusing whatever tracker it was handed — reusing
+ * one directly would let an override applied by some unrelated part of the
+ * tree that merely happens to share the same ambient `options` object (a
+ * later sibling reached through the same `itemOptions`, say) falsely mark
+ * *this* wrapper's own verbatim source as stale. But a genuinely *nested*
+ * app-sequence (e.g. a custom `wrap<<ilbs<<h'61'>>>>` extension wrapping an
+ * `ilbs<<...>>` result) must still have its own outer verbatim source
+ * abandoned when the inner wrapper's own tracked render found something to
+ * apply — an inner override changes what the outer source would need to
+ * embed too. So once this call's own local tracker comes back `applied`,
+ * that fact is additionally bubbled up to whichever ancestor tracker (if
+ * any) this call itself received via `options` — the exact wrapper this
+ * call is nested inside, never a sibling reached only through shared
+ * top-level `options`.
+ *
  * CBOR encoding and JS conversion always delegate to the inner item so the
  * wrapper is fully transparent for those operations.
  */
@@ -21,7 +54,29 @@ export declare class CborAppSeqResult extends CborItem {
     readonly ednSource: string;
     constructor(inner: CborItem, ednSource: string);
     get _containsCdnContainer(): boolean;
+    /**
+     * Same approach as `CborTag`: tokenize this wrapper's own `_toCDN()`
+     * output rather than delegating to `this.inner._isMultiWordText()`.
+     * Delegating to `this.inner` was tried and found wrong: for
+     * `ilbs<<h'68656c6c6f20776f726c64'>>`, the chunk's raw bytes decode to
+     * printable "hello world", so `this.inner`'s own semantic check reports
+     * it as multi-word — but the *actual* rendering is the preserved
+     * `ilbs<<...>>` app-sequence spelling, where that chunk appears as a
+     * `h'...'` literal, never as decoded text; the semantic prediction and
+     * the real output disagree. Tokenizing `this._toCDN()` directly sees
+     * whichever one actually happens: the preserved `ednSource` verbatim
+     * (`isMultiWordRenderedLiteral` peels the `prefix<<...>>` wrapper and
+     * checks each item under the loose rule, same as `<<...>>` — a
+     * multi-word text item like `ilts<<"two words">>` still always counts,
+     * a prefixed-literal item like `ilbs<<h'00'>>` does not) or, in the
+     * 'always'/'never' `encodingIndicators` modes, a pure passthrough to
+     * `this.inner._toCDN()` with no extra wrapping (any node needing that to
+     * be caught, like a self-disqualifying `CborIndefiniteByteString`, has
+     * already produced a `\n` in that string, which the caller's own
+     * `s.includes('\n')` check picks up independently either way).
+     */
+    _isMultiWordText(options: ToCDNOptions | undefined, strict?: boolean, path?: readonly unknown[]): boolean;
     _encodeTo(writer: CborWriter, options?: ToCBOROptions): void;
-    _toCDN(options: ToCDNOptions | undefined, depth: number): string;
-    _toJS(options?: ToJSOptions): unknown;
+    _toCDN(options: ToCDNOptions | undefined, depth: number, path?: readonly unknown[]): string;
+    _toJS(options?: ToJSOptions, path?: readonly unknown[], occurrence?: Occurrence): unknown;
 }

package/dist/ast/CborArray.d.ts

@@ -12,7 +12,7 @@ export declare class CborArray extends CborItem {
     });
     get _containsCdnContainer(): boolean;
     _encodeTo(writer: CborWriter, options?: ToCBOROptions): void;
-    _toCDN(options: ToCDNOptions | undefined, depth: number): string;
+    _toCDN(options: ToCDNOptions | undefined, depth: number, path?: readonly unknown[]): string;
     _toHexDump(depth: number, options?: ToCDNOptions): AnnotatedLine[];
-    _toJS(options?: ToJSOptions): unknown;
+    _toJS(options?: ToJSOptions, path?: readonly unknown[], occurrence?: readonly unknown[]): unknown;
 }

package/dist/ast/CborByteString.d.ts

@@ -48,7 +48,23 @@ export declare class CborByteString extends CborItem {
         ednCommentSyntax?: ByteCommentSyntax;
         ednParts?: readonly CborByteStringPart[];
     });
+    /**
+     * Only the "bare sqstr text with 2+ words" case — the "is this a
+     * prefixed literal" question is deliberately *not* predicted here from
+     * raw bytes at all (a subclass like `CborIpExt` might override `_toCDN()`
+     * to render something else entirely, e.g. a preserved
+     * `ip<<'192.0.2.42'>>` app-sequence spelling, that raw-byte prediction
+     * knows nothing about — see `isMultiWordByteString`'s doc). That
+     * question is instead answered from the *actual rendering*: for a bare
+     * entry, `serializeContainer`'s own `isPrefixedLiteralText(s)` check
+     * already covers it (this node's render *is* `s`, unobscured); for one
+     * wrapped in a `CborTag`, `CborTag._isMultiWordText`'s
+     * `isMultiWordRenderedLiteral` check covers it instead. `strict` isn't
+     * needed here at all now — it's accepted purely for interface
+     * consistency with the base class.
+     */
+    _isMultiWordText(options: ToCDNOptions | undefined, _strict?: boolean, _path?: readonly unknown[]): boolean;
     _encodeTo(writer: CborWriter, _options?: ToCBOROptions): void;
-    _toCDN(options: ToCDNOptions | undefined, _depth: number): string;
+    _toCDN(options: ToCDNOptions | undefined, _depth: number, _path?: readonly unknown[]): string;
     _toJS(_options?: ToJSOptions): unknown;
 }

package/dist/ast/CborEmbeddedCBOR.d.ts

@@ -2,7 +2,7 @@ import { ToCDNOptions, ToJSOptions, ToCBOROptions } from '../types';
 import { CborItem, AnnotatedLine } from './CborItem';
 import { CborWriter, EncodingWidth } from '../cbor/encode';
 /**
- * CBOR Sequence Literal (§2.5.6) — `<<item, item, ...>>`.
+ * CBOR Sequence Literal (§2.3.4) — `<<item, item, ...>>`.
  *
  * Encodes as a definite-length byte string whose value is the concatenation
  * of the CBOR encodings of the contained items.
@@ -21,7 +21,7 @@ export declare class CborEmbeddedCBOR extends CborItem {
     /** The raw concatenated CBOR bytes of all contained items. */
     private _content;
     _encodeTo(writer: CborWriter, options?: ToCBOROptions): void;
-    _toCDN(options: ToCDNOptions | undefined, depth: number): string;
+    _toCDN(options: ToCDNOptions | undefined, depth: number, path?: readonly unknown[]): string;
     _toHexDump(depth: number, options?: ToCDNOptions): AnnotatedLine[];
     _toJS(_options?: ToJSOptions): unknown;
 }

package/dist/ast/CborFloat.d.ts

@@ -22,7 +22,7 @@ export declare class CborFloat extends CborItem {
     /**
      * Original app-string source (e.g. `float'7e00'`), set by the parser when
      * this float is the result of a `float'...'` app-string.  Used by toCDN()
-     * to round-trip the literal when `appStrings` is not false.
+     * to round-trip the literal when `appPrefix` is not false.
      */
     ednSource?: string;
     /**
@@ -48,6 +48,6 @@ export declare class CborFloat extends CborItem {
         literalSource?: string;
     });
     _encodeTo(writer: CborWriter, _options?: ToCBOROptions): void;
-    _toCDN(options: ToCDNOptions | undefined, _depth: number): string;
+    _toCDN(options: ToCDNOptions | undefined, _depth: number, _path?: readonly unknown[]): string;
     _toJS(_options?: ToJSOptions): unknown;
 }

package/dist/ast/CborIndefiniteByteString.d.ts

@@ -8,7 +8,31 @@ export declare class CborIndefiniteByteString extends CborItem {
     readonly chunks: CborByteString[];
     constructor(chunks: CborByteString[]);
     _encodeTo(writer: CborWriter, options?: ToCBOROptions): void;
-    _toCDN(options: ToCDNOptions | undefined, depth: number): string;
+    /**
+     * True when any chunk's own decoded content, if it renders as bare sqstr
+     * text, has two or more words. Reachable when this node is a *direct*
+     * entry of another container (`[(_ "two words")]`) — though even then,
+     * its own `_toCDN()` already self-disqualifies internally in that case
+     * (a multi-word chunk forces a multi-line self-render), which the
+     * ordinary "entry's own rendering has a line break" check would catch
+     * regardless of what this method answers, so this mostly exists for
+     * robustness/consistency with `CborTextString`/`CborByteString` rather
+     * than because some case is otherwise unreachable.
+     *
+     * `CborAppSeqResult`, which wraps this node for results like
+     * `ilbs<<...>>`, does *not* delegate to this method — it tokenizes its
+     * own rendered output directly instead (`isMultiWordRenderedLiteral`),
+     * which is exactly why `ilbs<<h'00'>>` stays an ordinary leaf (checked
+     * under the loose rule, matching `<<...>>`) while `[h'00']`/`(_ h'00')`
+     * still always disqualify — this method's own `_strict` (always `true`,
+     * matching how a chunk renders when this container *is* regenerated
+     * directly) plays no part in that distinction anymore, and a byte string
+     * chunk's own `_isMultiWordText` doesn't consult `strict` at all
+     * regardless (see `CborByteString`'s doc — its "prefixed literal" case
+     * was removed there too).
+     */
+    _isMultiWordText(options: ToCDNOptions | undefined, _strict?: boolean): boolean;
+    _toCDN(options: ToCDNOptions | undefined, depth: number, path?: readonly unknown[]): string;
     _toHexDump(depth: number, options?: ToCDNOptions): AnnotatedLine[];
     _toJS(_options?: ToJSOptions): unknown;
 }

package/dist/ast/CborIndefiniteTextString.d.ts

@@ -8,7 +8,23 @@ export declare class CborIndefiniteTextString extends CborItem {
     readonly chunks: CborTextString[];
     constructor(chunks: CborTextString[]);
     _encodeTo(writer: CborWriter, options?: ToCBOROptions): void;
-    _toCDN(options: ToCDNOptions | undefined, depth: number): string;
+    /**
+     * True when any chunk is multi-word. Reachable when this node is a
+     * *direct* entry of another container (`[(_ "two words")]`) — though even
+     * then, its own `_toCDN()` already self-disqualifies internally in that
+     * case, producing a multi-line self-render that the ordinary "entry's own
+     * rendering has a line break" check would catch regardless of what this
+     * method answers, so this mostly exists for robustness/consistency with
+     * `CborTextString`/`CborByteString` rather than because some case is
+     * otherwise unreachable. (`CborAppSeqResult`, which wraps this node for
+     * results like `ilts<<...>>`, does *not* delegate to this method — it
+     * tokenizes its own rendered output directly instead; see its doc for
+     * why that turned out to be necessary.) `_strict` is intentionally
+     * unused: a chunk is always CborTextString, whose own word count doesn't
+     * depend on it.
+     */
+    _isMultiWordText(options: ToCDNOptions | undefined, _strict?: boolean): boolean;
+    _toCDN(options: ToCDNOptions | undefined, depth: number, path?: readonly unknown[]): string;
     _toHexDump(depth: number, options?: ToCDNOptions): AnnotatedLine[];
     _toJS(_options?: ToJSOptions): unknown;
 }