chore(deps): bump @o3co/ts.hocon from 1.2.0 to 1.7.0

[dependabot]

Bumps @o3co/ts.hocon from 1.2.0 to 1.7.0.

Release notes

Sourced from @​o3co/ts.hocon's releases.

v1.7.0

Cross-impl release coordinated to land at v1.7.0 across go.hocon / ts.hocon / rs.hocon. The minor bump is driven by go.hocon's new GetXxxE accessor family (go.hocon#142, additive public API); ts.hocon's content for this cycle is the cross-impl leading-zero JSON-render validity fix (xx.hocon#50, byte-aligned with go.hocon's equivalent fix) — no new ts-side public API, but the version syncs with go/rs per project convention. No breaking changes; safe drop-in upgrade from v1.6.1. package.json stays at "0.0.0-snapshot"; the release workflow bumps from the tag.

Fixed — leading-zero numeric values render as valid canonical JSON (xx.hocon#50)

• Leading-zero numeric value literals now render as canonical JSON numbers (Lightbend / rs.hocon parity). renderHoconAsJSON emitted numeric-value lexemes verbatim, so b = 023 / c = 08.53 produced {"b":023,"c":08.53} — not valid JSON, and divergent from Lightbend/rs (which emit 23 / 8.53). The renderer now strips redundant leading zeros from the integer part of a number lexeme before emitting (023→23, -08.53→-8.53, 007→7; 0, 0.5, 1.0 unchanged), matching the xx.hocon lzv01 cross-impl fixture and byte-identical to go.hocon's equivalent fix. Render-only: getString/concat still return the verbatim source lexeme (S10.11), so getString('0100') is unchanged. The broader numeric-canonical family (exponent 1e3→1000.0, trailing-zero 1.50→1.5, -0→0) is a separate, untested convergence tracked as a follow-up. No public API change. Pinned by tests/deferred-resolution.test.ts.

v1.6.1

Bugfix release: S13b.2 += accumulation across includes (go.hocon#134) — the follow-up deferred from v1.6.0. No public API changes; safe drop-in upgrade from v1.6.0. package.json stays at "0.0.0-snapshot"; the release workflow bumps from the tag.

Fixed — S13b.2 += accumulation across includes (go.hocon#134)

• Repeated += array appends across included files now accumulate in document order, matching Lightbend's treat-includes-as-textual-inlining semantics (HOCON.md L732, a += b ≡ a = ${?a} [b]). include "first" (items += "a"); include "second" (items += "b"); items += "main" now yields ["a", "b", "main"] instead of dropping earlier includes' elements. += was an eager-snapshot AppendPlaceholder whose existing was captured in each included file's isolated scope, so the cross-include merge overwrote it. The fix desugars += to the fully-qualified ${?key} [b] self-ref concat at structure-build time (StructureBuilder.desugarAppend), so it flows through the chained-self-ref machinery (#131/#120). deepMergeResObjInto now splices the destination's pre-merge value into the included chain's knownAbsent bottom (foldKnownAbsentSelfRef), and reset semantics (an explicit k = [...] before a k +=, in an included file or the parent) are tracked via a new ResObj.resetKeys origin flag — distinguishing a reset from a within-file += chain (which also records a prior). The eager AppendPlaceholder variant and resolveAppend are removed. The same fold discipline is applied in mergeUnresolved (the E12 withFallback path) so a deferred withFallback whose fallback uses += accumulates correctly (parseStringWithOptions('items += "r"', deferred).withFallback(parseStringWithOptions('items += "f"', deferred)).resolve() → ['f','r']) instead of throwing a stack overflow. No public API change. Pinned by 15 tests in tests/issue134-plus-equals-include.test.ts, including within-file += chains inside a later include merged onto a non-empty destination, multi-write includes, nested-path, prefix-mounted includes, the deferred withFallback + += case, and += [array] single-element nesting / degenerate self-ref.

v1.6.0

Cross-impl release coordinated to land at v1.6.0 across go.hocon / ts.hocon / rs.hocon. Covers: E6 cross-source list-suffix env-fallback ordering (xx.hocon#22 C4), C3 cluster 3h cross-impl resolver bugs (xx.hocon#27 — E14, sr13–sr16), E13 key-position parsing alignment (xx.hocon#42), cross-impl regression coverage for go.hocon#128 include-child env-with-default (ts.hocon is structurally immune — these tests pin the invariant), and the S10.5 string-concat whitespace fix (go.hocon#132) from the go.hocon#131–#135 audit. (go.hocon#134 — += accumulation across includes — also applies to ts.hocon but is deferred to a follow-up: the correct fix is a resolver-chain change that needs the multi-agent-review treatment the chained-self-ref machinery already required. go.hocon#133 numeric-lexeme is N/A — ts.hocon already preserves the lexeme.) No public API changes; safe drop-in upgrade from v1.5.2. The release line skips v1.5.3 for ts.hocon to align all three impls at v1.6.0. package.json stays at "0.0.0-snapshot"; the release workflow bumps from the tag.

Fixed — S10.5 inner whitespace in value concatenation (go.hocon#132)

• Literal whitespace runs between simple values in a string concatenation are now preserved verbatim (HOCON.md §String value concatenation L332). parseValue inserted a single hardcoded ' ' separator between concat pieces, collapsing every multi-space run to one space (foo bar → "foo bar", and "left" ${?UNSET} "right" → "left right" instead of Lightbend's "left right"). The fix threads t.precedingWhitespace (the lexer field E13 already added for key-position whitespace) into the value-position separator. Single-space concatenations are unchanged. One incidental side effect: a lone CR (0x0D, not a newline per S6.5) between simple values is now preserved verbatim rather than collapsed to a space — impl-lenient behaviour with no Lightbend ground truth (Lightbend rejects x = 1\ry = 2), cross-impl consistent with rs.hocon. Pinned by 6 tests in tests/s10-5-concat-whitespace.test.ts.

Fixed — E6 cross-source list-suffix env-fallback ordering (xx.hocon#22 C4)

• ${X} / ${X[]} in an included file now consults the original config path before any env-var fallback (xx.hocon#22 C4). Port of rs.hocon substitution_resolver.rs:443–493 into ts.hocon's SubstitutionResolver.resolveSubst: after the primary lookupPath branch and before the listSuffix / scalar-env branches, fall back to lookupPath(this.root, segments[prefixLen..]) so a substitution inside an included file (relativized to ${prefix.X}) still sees X defined at the parent's root, matching Lightbend 1.4.6 ResolveSource.java:100–130 order: primary → S14c.2 → listSuffix → scalar-env. Includes a delayed-merge mirror guard so the original-path fallback does not race with structure-build-time merge fixup (cluster spec §8 + rs.hocon#44). S13c.5 invariant preserved: ev12a (required ${X[]} with no _0 env) still throws ResolveError. ev12c-include-config-defined-wins added to the env-var-list success suite as the cross-source pin.

Fixed — C3 cluster 3h cross-impl resolver bugs (xx.hocon#27 — E14, sr13–sr16)

• sr15 — universal "drop first concat" cross-impl resolver bug (xx.hocon#27). Optional self-references with no prior value at save time previously caused foldOrSkipPrior to skip the prior-save, so the first concat in chains like a = ${?a} [...]; a = ${?a} [...] dropped its element. Fix introduces a SubstPlaceholder.knownAbsent sentinel — optional no-prior self-refs fold to the sentinel rather than skipping the save. The sentinel resolves to undefined in resolveSubst and is ignored by pointer-identity self-ref detection. Container-aware via the existing concat/array/object recursion.
• sr13 — post-fold overwrite regression. Adjacent to the sr15 fix, the prior is now saved BEFORE foldNestedSelfRefs, and the structure-builder gate that previously suppressed the fold when existing was a plain ResObj is removed (always fold when existing is ResObj). Pinned by 20 new unit tests in tests/fold-self-ref-unit.test.ts covering all foldOptionalSelfRefAbsent branches (Append / ResObj / HoconArray / HoconObject / fallback).
• sr14 / sr16 — cache pollution on prior-with-external-ref / order-dependent external-then-self-ref. resolveResObj now invalidates the cache before resolving each field, writes the authoritative resolved value after, and recursively caches descendants. Combined with the round-2 Codex P1 fix to shouldFoldNested gate (o.a="x"; o.a=${?o.a}bar; o=${?o} repro) and the stringSegmentsToKey escape for resolvingFieldPath join (dotted-key cache collision), the four bugs are fixed under a single shared shape.

Changed — E13 key-position parsing (xx.hocon #42)

• S8.6 is no longer enforced on key path segments — foo -bar = 1, foo.-bar = 1, -foo bar = 1, foo -1bar = 1 etc. now parse verbatim per Lightbend 1.4.3. The HOCON.md L270-276 "begin with - requires digit" rule is a value-position lexer-disambiguation rule (governed by E8 in xx.hocon extra-spec-conventions); key-position is governed by path-element parsing rules where Lightbend takes characters verbatim. Pinned by 8 new fixtures (key-hyphen-position/kh01–kh08) in xx.hocon main. Pure loosening — no previously-valid input is now rejected.
• Path-expression whitespace adjacent to dots is preserved verbatim — a b. c = 1 → {"a b":{" c":1}} (leading space on " c" preserved); a b.\tc = 1 → {"a b":{"\tc":1}} (HOCON_WS tab uniformly preserved); a .b = 1 → {"a ":{"b":1}} (trailing space on "a " preserved). Per Lightbend's char-by-char path parsing. Pinned by 6 new fixtures (path-expr-whitespace/pw01–pw05, pw07) + 1 error fixture (pw06: a b. = 1 → BadPath, loosening does NOT cascade into empty path segments). See xx.hocon E13.
• Behavior change — key string normalisation no longer fires for path-WS-adjacent-to-dot inputs. Inputs like a .b = X previously produced path ["a", "b"]; now produce ["a ", "b"]. Inputs that worked via cfg.getString("a.b") lookup (after the path key was implicitly trimmed) will need to use the literal key "a b" or "a " if they were relying on the prior trimming. Also: tab between key tokens is now preserved (was normalised to single ASCII space) — a\tb = 1 now yields key ["a\tb"] instead of ["a b"]. Narrow set of affected inputs.
• Bundled fix — trailing-dot key paths now consistently reject. foo. = 1, a.b. = 1, a b. = 1, and a. . = 1 now throw ParseError ("path has a trailing period — empty key segment not allowed"). Pre-E13 these silently parsed to the prefix segments (e.g. foo. = 1 → {"foo":1}). Aligned with Lightbend BadPath and E13 boundary fixture pw06. Leading-dot (.foo = 1) and double-dot (a..b = 1) in key paths are NOT addressed in this PR (pre-existing silent-accept gap, no xx.hocon fixture yet — tracked as a follow-up).
• Bundled fix — dot-WS-dot in key paths produces a WS segment per Lightbend. a. .b = 1 now yields ["a", " ", "b"] (was ["a", " b"] from the initial E13 patch; Lightbend probe confirms {"a":{" ":{"b":1}}}). Caught by Codex multi-agent-review on this PR.

Implementation

• Lexer: Token.precedingWhitespace: string field added (the literal whitespace chars consumed since the previous token). Token.precedingSpace: boolean retained for clarity at call sites. The two fields are related but not equivalent: comments set hadSpace=true without contributing chars to the whitespace buffer, so the newline token emitted immediately after a // foo\n or # foo\n comment carries precedingSpace=true while precedingWhitespace="". precedingSpace is the right signal for concat detection (S10.5 / S10.8); precedingWhitespace is the right signal for path-WS preservation (E13). See src/internal/lexer/token.ts for the full rationale.
• Parser parseKey: S8.6-in-key check removed; literal ' ' joiner in space-concat replaced with t.precedingWhitespace; post-trailing-dot iteration captures next token's precedingWhitespace as postDotPrefix and prepends to next segment; post-loop guard rejects trailing-dot-before-separator (matches Lightbend BadPath behavior).

Tests — cross-impl regression coverage for go.hocon#128

• Pin include-child ${?ENV} env-with-default semantics so a future refactor to a multi-pass shape can't silently regress to go.hocon's pre-fix shape (go.hocon#128 — fixed in go.hocon v1.5.3 / go.hocon#129). 5 new tests in tests/issue128-include-env-fallback.test.ts: include "file" env-unset / env-set, include package(...) env-unset / env-set, deferred-resolve path env-unset. Env is injected via ParseOptions.env (no process.env mutation) per the cross-impl hermeticity convention. ts.hocon's single-pass substitution-resolve over a merge-time-populated priorValues (via deepMergeResObjInto) is structurally immune to the go.hocon bug, but the tests pin that invariant.

... (truncated)

Changelog

Sourced from @​o3co/ts.hocon's changelog.

[1.7.0] - 2026-05-30

Cross-impl release coordinated to land at v1.7.0 across go.hocon / ts.hocon / rs.hocon. The minor bump is driven by go.hocon's new GetXxxE accessor family (go.hocon#142, additive public API); ts.hocon's content for this cycle is the cross-impl leading-zero JSON-render validity fix (xx.hocon#50, byte-aligned with go.hocon's equivalent fix) — no new ts-side public API, but the version syncs with go/rs per project convention. No breaking changes; safe drop-in upgrade from v1.6.1. package.json stays at "0.0.0-snapshot"; the release workflow bumps from the tag.

Fixed — leading-zero numeric values render as valid canonical JSON (xx.hocon#50)

• Leading-zero numeric value literals now render as canonical JSON numbers (Lightbend / rs.hocon parity). renderHoconAsJSON emitted numeric-value lexemes verbatim, so b = 023 / c = 08.53 produced {"b":023,"c":08.53} — not valid JSON, and divergent from Lightbend/rs (which emit 23 / 8.53). The renderer now strips redundant leading zeros from the integer part of a number lexeme before emitting (023→23, -08.53→-8.53, 007→7; 0, 0.5, 1.0 unchanged), matching the xx.hocon lzv01 cross-impl fixture and byte-identical to go.hocon's equivalent fix. Render-only: getString/concat still return the verbatim source lexeme (S10.11), so getString('0100') is unchanged. The broader numeric-canonical family (exponent 1e3→1000.0, trailing-zero 1.50→1.5, -0→0) is a separate, untested convergence tracked as a follow-up. No public API change. Pinned by tests/deferred-resolution.test.ts.

[1.6.1] - 2026-05-29

Bugfix release: S13b.2 += accumulation across includes (go.hocon#134) — the follow-up deferred from v1.6.0. No public API changes; safe drop-in upgrade from v1.6.0. package.json stays at "0.0.0-snapshot"; the release workflow bumps from the tag.

Fixed — S13b.2 += accumulation across includes (go.hocon#134)

• Repeated += array appends across included files now accumulate in document order, matching Lightbend's treat-includes-as-textual-inlining semantics (HOCON.md L732, a += b ≡ a = ${?a} [b]). include "first" (items += "a"); include "second" (items += "b"); items += "main" now yields ["a", "b", "main"] instead of dropping earlier includes' elements. += was an eager-snapshot AppendPlaceholder whose existing was captured in each included file's isolated scope, so the cross-include merge overwrote it. The fix desugars += to the fully-qualified ${?key} [b] self-ref concat at structure-build time (StructureBuilder.desugarAppend), so it flows through the chained-self-ref machinery (#131/#120). deepMergeResObjInto now splices the destination's pre-merge value into the included chain's knownAbsent bottom (foldKnownAbsentSelfRef), and reset semantics (an explicit k = [...] before a k +=, in an included file or the parent) are tracked via a new ResObj.resetKeys origin flag — distinguishing a reset from a within-file += chain (which also records a prior). The eager AppendPlaceholder variant and resolveAppend are removed. The same fold discipline is applied in mergeUnresolved (the E12 withFallback path) so a deferred withFallback whose fallback uses += accumulates correctly (parseStringWithOptions('items += "r"', deferred).withFallback(parseStringWithOptions('items += "f"', deferred)).resolve() → ['f','r']) instead of throwing a stack overflow. No public API change. Pinned by 15 tests in tests/issue134-plus-equals-include.test.ts, including within-file += chains inside a later include merged onto a non-empty destination, multi-write includes, nested-path, prefix-mounted includes, the deferred withFallback + += case, and += [array] single-element nesting / degenerate self-ref.

[1.6.0] - 2026-05-27

Cross-impl release coordinated to land at v1.6.0 across go.hocon / ts.hocon / rs.hocon. Covers: E6 cross-source list-suffix env-fallback ordering (xx.hocon#22 C4), C3 cluster 3h cross-impl resolver bugs (xx.hocon#27 — E14, sr13–sr16), E13 key-position parsing alignment (xx.hocon#42), cross-impl regression coverage for go.hocon#128 include-child env-with-default (ts.hocon is structurally immune — these tests pin the invariant), and the S10.5 string-concat whitespace fix (go.hocon#132) from the go.hocon#131–#135 audit. (go.hocon#134 — += accumulation across includes — also applies to ts.hocon but is deferred to a follow-up: the correct fix is a resolver-chain change that needs the multi-agent-review treatment the chained-self-ref machinery already required. go.hocon#133 numeric-lexeme is N/A — ts.hocon already preserves the lexeme.) No public API changes; safe drop-in upgrade from v1.5.2. The release line skips v1.5.3 for ts.hocon to align all three impls at v1.6.0. package.json stays at "0.0.0-snapshot"; the release workflow bumps from the tag.

Fixed — S10.5 inner whitespace in value concatenation (go.hocon#132)

• Literal whitespace runs between simple values in a string concatenation are now preserved verbatim (HOCON.md §String value concatenation L332). parseValue inserted a single hardcoded ' ' separator between concat pieces, collapsing every multi-space run to one space (foo bar → "foo bar", and "left" ${?UNSET} "right" → "left right" instead of Lightbend's "left right"). The fix threads t.precedingWhitespace (the lexer field E13 already added for key-position whitespace) into the value-position separator. Single-space concatenations are unchanged. One incidental side effect: a lone CR (0x0D, not a newline per S6.5) between simple values is now preserved verbatim rather than collapsed to a space — impl-lenient behaviour with no Lightbend ground truth (Lightbend rejects x = 1\ry = 2), cross-impl consistent with rs.hocon. Pinned by 6 tests in tests/s10-5-concat-whitespace.test.ts.

Fixed — E6 cross-source list-suffix env-fallback ordering (xx.hocon#22 C4)

• ${X} / ${X[]} in an included file now consults the original config path before any env-var fallback (xx.hocon#22 C4). Port of rs.hocon substitution_resolver.rs:443–493 into ts.hocon's SubstitutionResolver.resolveSubst: after the primary lookupPath branch and before the listSuffix / scalar-env branches, fall back to lookupPath(this.root, segments[prefixLen..]) so a substitution inside an included file (relativized to ${prefix.X}) still sees X defined at the parent's root, matching Lightbend 1.4.6 ResolveSource.java:100–130 order: primary → S14c.2 → listSuffix → scalar-env. Includes a delayed-merge mirror guard so the original-path fallback does not race with structure-build-time merge fixup (cluster spec §8 + rs.hocon#44). S13c.5 invariant preserved: ev12a (required ${X[]} with no _0 env) still throws ResolveError. ev12c-include-config-defined-wins added to the env-var-list success suite as the cross-source pin.

Fixed — C3 cluster 3h cross-impl resolver bugs (xx.hocon#27 — E14, sr13–sr16)

• sr15 — universal "drop first concat" cross-impl resolver bug (xx.hocon#27). Optional self-references with no prior value at save time previously caused foldOrSkipPrior to skip the prior-save, so the first concat in chains like a = ${?a} [...]; a = ${?a} [...] dropped its element. Fix introduces a SubstPlaceholder.knownAbsent sentinel — optional no-prior self-refs fold to the sentinel rather than skipping the save. The sentinel resolves to undefined in resolveSubst and is ignored by pointer-identity self-ref detection. Container-aware via the existing concat/array/object recursion.
• sr13 — post-fold overwrite regression. Adjacent to the sr15 fix, the prior is now saved BEFORE foldNestedSelfRefs, and the structure-builder gate that previously suppressed the fold when existing was a plain ResObj is removed (always fold when existing is ResObj). Pinned by 20 new unit tests in tests/fold-self-ref-unit.test.ts covering all foldOptionalSelfRefAbsent branches (Append / ResObj / HoconArray / HoconObject / fallback).
• sr14 / sr16 — cache pollution on prior-with-external-ref / order-dependent external-then-self-ref. resolveResObj now invalidates the cache before resolving each field, writes the authoritative resolved value after, and recursively caches descendants. Combined with the round-2 Codex P1 fix to shouldFoldNested gate (o.a="x"; o.a=${?o.a}bar; o=${?o} repro) and the stringSegmentsToKey escape for resolvingFieldPath join (dotted-key cache collision), the four bugs are fixed under a single shared shape.

Changed — E13 key-position parsing (xx.hocon #42)

• S8.6 is no longer enforced on key path segments — foo -bar = 1, foo.-bar = 1, -foo bar = 1, foo -1bar = 1 etc. now parse verbatim per Lightbend 1.4.3. The HOCON.md L270-276 "begin with - requires digit" rule is a value-position lexer-disambiguation rule (governed by E8 in xx.hocon extra-spec-conventions); key-position is governed by path-element parsing rules where Lightbend takes characters verbatim. Pinned by 8 new fixtures (key-hyphen-position/kh01–kh08) in xx.hocon main. Pure loosening — no previously-valid input is now rejected.
• Path-expression whitespace adjacent to dots is preserved verbatim — a b. c = 1 → {"a b":{" c":1}} (leading space on " c" preserved); a b.\tc = 1 → {"a b":{"\tc":1}} (HOCON_WS tab uniformly preserved); a .b = 1 → {"a ":{"b":1}} (trailing space on "a " preserved). Per Lightbend's char-by-char path parsing. Pinned by 6 new fixtures (path-expr-whitespace/pw01–pw05, pw07) + 1 error fixture (pw06: a b. = 1 → BadPath, loosening does NOT cascade into empty path segments). See xx.hocon E13.
• Behavior change — key string normalisation no longer fires for path-WS-adjacent-to-dot inputs. Inputs like a .b = X previously produced path ["a", "b"]; now produce ["a ", "b"]. Inputs that worked via cfg.getString("a.b") lookup (after the path key was implicitly trimmed) will need to use the literal key "a b" or "a " if they were relying on the prior trimming. Also: tab between key tokens is now preserved (was normalised to single ASCII space) — a\tb = 1 now yields key ["a\tb"] instead of ["a b"]. Narrow set of affected inputs.
• Bundled fix — trailing-dot key paths now consistently reject. foo. = 1, a.b. = 1, a b. = 1, and a. . = 1 now throw ParseError ("path has a trailing period — empty key segment not allowed"). Pre-E13 these silently parsed to the prefix segments (e.g. foo. = 1 → {"foo":1}). Aligned with Lightbend BadPath and E13 boundary fixture pw06. Leading-dot (.foo = 1) and double-dot (a..b = 1) in key paths are NOT addressed in this PR (pre-existing silent-accept gap, no xx.hocon fixture yet — tracked as a follow-up).
• Bundled fix — dot-WS-dot in key paths produces a WS segment per Lightbend. a. .b = 1 now yields ["a", " ", "b"] (was ["a", " b"] from the initial E13 patch; Lightbend probe confirms {"a":{" ":{"b":1}}}). Caught by Codex multi-agent-review on this PR.

Implementation

• Lexer: Token.precedingWhitespace: string field added (the literal whitespace chars consumed since the previous token). Token.precedingSpace: boolean retained for clarity at call sites. The two fields are related but not equivalent: comments set hadSpace=true without contributing chars to the whitespace buffer, so the newline token emitted immediately after a // foo\n or # foo\n comment carries precedingSpace=true while precedingWhitespace="". precedingSpace is the right signal for concat detection (S10.5 / S10.8); precedingWhitespace is the right signal for path-WS preservation (E13). See src/internal/lexer/token.ts for the full rationale.
• Parser parseKey: S8.6-in-key check removed; literal ' ' joiner in space-concat replaced with t.precedingWhitespace; post-trailing-dot iteration captures next token's precedingWhitespace as postDotPrefix and prepends to next segment; post-loop guard rejects trailing-dot-before-separator (matches Lightbend BadPath behavior).

Tests — cross-impl regression coverage for go.hocon#128

• Pin include-child ${?ENV} env-with-default semantics so a future refactor to a multi-pass shape can't silently regress to go.hocon's pre-fix shape (go.hocon#128 — fixed in go.hocon v1.5.3 / go.hocon#129). 5 new tests in tests/issue128-include-env-fallback.test.ts: include "file" env-unset / env-set, include package(...) env-unset / env-set, deferred-resolve path env-unset. Env is injected via ParseOptions.env (no process.env mutation) per the cross-impl hermeticity convention. ts.hocon's single-pass substitution-resolve over a merge-time-populated priorValues (via deepMergeResObjInto) is structurally immune to the go.hocon bug, but the tests pin that invariant.

... (truncated)

Commits

• 88466d6 release(v1.7.0): finalize CHANGELOG for the cross-impl v1.7.0 sync
• 168631c fix(render): canonicalize leading-zero numeric values in JSON output (xx.hoco...
• 4f514c5 release(v1.6.1): go.hocon#134 += include accumulation (#143)
• 237b60d fix(resolver): S13b.2 — accumulate += across include boundaries (go.hocon#134)
• 68c5485 fix(tooling): plain .mjs hocon-json adapter (Copilot review)
• f6baf15 feat(tooling): hocon-json adapter for the differential harness
• cb543dd fix(parser): S10.5 — preserve literal whitespace in value concat + cut v1.6.0...
• 478deba docs(changelog): unify cluster 3h label (E14 + sr13–sr16) per Copilot review ...
• 969407e release(v1.5.3): finalize CHANGELOG — cross-impl spec compliance + go.hocon#1...
• 3b7e047 test(resolver): inject env via ParseOptions.env (Copilot #138)
• Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

[dependabot]

Superseded by #48.