@o3co/ts.hocon 1.9.0 → 1.11.0

package/dist/adapters/jsonc.d.cts

@@ -0,0 +1,45 @@
+import { C as Config } from '../config-Dlq6rF3w.cjs';
+
+/**
+ * Read JSON with comments and trailing commas — the dialect VS Code and
+ * TypeScript use for their config files — as HOCON config.
+ *
+ * Plain JSON needs no adapter at all: HOCON is a JSON superset, so `parse`
+ * already accepts a .json file. This exists for the two things HOCON does not
+ * accept, block comments and trailing commas. (HOCON has `//` and `#` comments
+ * of its own.)
+ *
+ * Comments and trailing commas are removed and `JSON.parse` does the rest, so
+ * the accepted grammar is otherwise exactly the platform's JSON. A comment is
+ * replaced by whitespace rather than deleted, so it separates the tokens around
+ * it and `{"a":1/*x*\/2}` is a syntax error rather than `{"a":12}` (F3.2).
+ *
+ * Integers are ingested losslessly (F0.5): a literal too wide for a JS `number`
+ * keeps its digits — `getString` returns them exactly — and one outside int64
+ * is refused instead of being rounded. `getNumber` and `toObject` still apply
+ * the JS number model, as they do for HOCON's own literals, so read large
+ * identifiers with `getString`.
+ *
+ * See docs/specs/format-ingestion-mapping.md items F3.x in the hocon scope.
+ */
+declare function parseJsonc(input: string, originDescription?: string): Config;
+/**
+ * Remove `//` line comments and block comments, leaving string literals alone.
+ *
+ * F3.2: a comment is replaced by *whitespace*, never the empty string — it must
+ * keep separating the tokens around it, so a `1`, a block comment and a `2` stay
+ * two tokens and fail the JSON decode instead of silently reading as `12`.
+ * Newlines inside a removed span are kept so JSON.parse still reports useful
+ * positions; a span with no newline becomes a single space.
+ *
+ * A `//` comment ends at **LF or CR** (F3.2), and at nothing else. Stopping only
+ * at LF let a CR-terminated comment eat the rest of the line, and the
+ * trailing-comma pass then tidied the remains into valid JSON — so
+ * `{"a":1,//c\r"b":2,\n"c":3}` decoded as `{"a":1,"c":3}`, losing a key with no
+ * error at all. Stopping at U+2028/U+2029 would be the mirror-image mistake:
+ * ending a comment the dialect's own parser is still inside, so the document
+ * would mean something different here than in VS Code. See {@link isLineBreak}.
+ */
+declare function stripComments(src: string): string;
+
+export { parseJsonc, stripComments };

package/dist/adapters/jsonc.d.ts

@@ -0,0 +1,45 @@
+import { C as Config } from '../config-Dlq6rF3w.js';
+
+/**
+ * Read JSON with comments and trailing commas — the dialect VS Code and
+ * TypeScript use for their config files — as HOCON config.
+ *
+ * Plain JSON needs no adapter at all: HOCON is a JSON superset, so `parse`
+ * already accepts a .json file. This exists for the two things HOCON does not
+ * accept, block comments and trailing commas. (HOCON has `//` and `#` comments
+ * of its own.)
+ *
+ * Comments and trailing commas are removed and `JSON.parse` does the rest, so
+ * the accepted grammar is otherwise exactly the platform's JSON. A comment is
+ * replaced by whitespace rather than deleted, so it separates the tokens around
+ * it and `{"a":1/*x*\/2}` is a syntax error rather than `{"a":12}` (F3.2).
+ *
+ * Integers are ingested losslessly (F0.5): a literal too wide for a JS `number`
+ * keeps its digits — `getString` returns them exactly — and one outside int64
+ * is refused instead of being rounded. `getNumber` and `toObject` still apply
+ * the JS number model, as they do for HOCON's own literals, so read large
+ * identifiers with `getString`.
+ *
+ * See docs/specs/format-ingestion-mapping.md items F3.x in the hocon scope.
+ */
+declare function parseJsonc(input: string, originDescription?: string): Config;
+/**
+ * Remove `//` line comments and block comments, leaving string literals alone.
+ *
+ * F3.2: a comment is replaced by *whitespace*, never the empty string — it must
+ * keep separating the tokens around it, so a `1`, a block comment and a `2` stay
+ * two tokens and fail the JSON decode instead of silently reading as `12`.
+ * Newlines inside a removed span are kept so JSON.parse still reports useful
+ * positions; a span with no newline becomes a single space.
+ *
+ * A `//` comment ends at **LF or CR** (F3.2), and at nothing else. Stopping only
+ * at LF let a CR-terminated comment eat the rest of the line, and the
+ * trailing-comma pass then tidied the remains into valid JSON — so
+ * `{"a":1,//c\r"b":2,\n"c":3}` decoded as `{"a":1,"c":3}`, losing a key with no
+ * error at all. Stopping at U+2028/U+2029 would be the mirror-image mistake:
+ * ending a comment the dialect's own parser is still inside, so the document
+ * would mean something different here than in VS Code. See {@link isLineBreak}.
+ */
+declare function stripComments(src: string): string;
+
+export { parseJsonc, stripComments };