deps: bump the patch group with 2 updates

[dependabot]

Bumps the patch group with 2 updates: @cldmv/eslint-plugin-jsonv and @cldmv/jsonv.

Updates @cldmv/eslint-plugin-jsonv from 1.0.10 to 1.0.13

Release notes

Sourced from @​cldmv/eslint-plugin-jsonv's releases.

v1.0.13

release: v1.0.13 - publish real types for the plugin, language and AST

@​cldmv/eslint-plugin-jsonv v1.0.13 Changelog

Release Date: September 2026 Release Type: Patch Branch: release/1.0.13

---

Overview

Version 1.0.13 makes the plugin's published types real. dist/index.d.mts used to declare the default export as a bare Object; it now types the plugin, the jsonv/jsonv language, JsonvSourceCode, and every AST node against @eslint/core's generics, and the JSDoc that generates those declarations is now type-checked in CI. The release also closes a gap the new types surfaced: engines.node and a missing eslint peer range now match what the plugin's runtime dependencies actually require. Alongside that, the plugin accepts three more @cldmv/jsonv language options, and the repository adopts the CLDMV lint/format tooling.

No configuration changes are required to pick this up — existing eslint.config.mjs files, rules, and languageOptions keep working unchanged.

---

🐛 Bug Fixes

Published types describe a real ESLint plugin (#30, fixes #28)

dist/index.d.mts declared const plugin: Object, so a TypeScript (or // @ts-check) config got no type for plugin.configs.recommended, plugin.languages.jsonv, or languageOptions, and nothing for a rule author to use for the AST node types the language exposes. The JSDoc in index.mjs is now typed against @eslint/core's Language, TextSourceCode, OkParseResult, and Plugin generics, the way @eslint/json types its JSON language, and tsconfig.types.json now type-checks it (checkJs: true) instead of only emitting from it. The package exports typedefs for every AST node (JsonvProgram, JsonvObjectExpression, JsonvProperty, JsonvLiteral, JsonvIdentifier, JsonvMemberExpression, JsonvTemplateLiteral, JsonvTemplateElement), for JsonvLanguageOptions, and for a rule's visitor (JsonvRuleDefinition, JsonvRuleVisitor), plus the JsonvSourceCode class itself, and JsonvSourceCode is now a named export alongside the default plugin. A new test:types script compiles a type-level consumer test against the built declarations the way an eslint.config.mts would, and build:ci runs it.

The declared Node floor and ESLint range match what the plugin needs (#37, fixes #32)

engines.node still said >=18.0.0, but the runtime dependencies added for real types — @eslint/core and @eslint/plugin-kit — both require ^20.19.0 || ^22.13.0 || >=24, and so does ESLint 10 itself. Installing on Node 18 could fail or warn while engines claimed support. engines.node now states that real floor, and a new eslint peer dependency (^9.13.0 || ^10.0.0) tells consumers which ESLint versions the plugin's languages API needs — ^9.13.0 is the first release with defaultLanguageOptions support for plugin languages.

mode, strictOctal, and allowInternalReferences language options (#39, fixes #34)

The README documented a mode option, and the plugin rejected it (Unknown language option "mode") because it was never actually forwarded to the parser. mode ("jsonv", "json5", or "json", default "jsonv"), strictOctal (boolean, default false), and allowInternalReferences (boolean, default true) are now accepted, validated, and passed through to both parseWithOptions() and parseToAst(), matching @cldmv/jsonv's own ParseOptions. reviver, preserveComments, and tolerant stay unsupported, and validateLanguageOptions now names the reason when one of those three is set instead of reporting it as merely unknown. The README's Configuration Options table documents all five options with their defaults, and a new test extracts the README's own languageOptions examples and runs them through validateLanguageOptions and a live Linter, so the docs and the code can't drift apart again.

🔧 CI & tooling

• The CLDMV eslint + prettier config, lint / lint:fix / format / format:check scripts, and the .githooks pre-commit hook are added, and the existing sources and README are reformatted repo-wide (#38, fixes #33).
• release-merge is re-armed on every check-producing workflow, instead of only the ones that existed when it was first wired (#40).
• The v4 workflows are synced with the CLDMV/.github v4.29.2 templates (#42).
• The bundle-size workflow is added, and the release-merge required-workflow list is restored to the full set (#43).

📚 Documentation

• NEW: docs/changelog/v1/v1.0.13.md — this changelog.
• README Installation now states the Node and ESLint requirements (#37).
• README Configuration Options documents mode, strictOctal, and allowInternalReferences alongside year and strictBigInt (#39).

🔧 Dependencies

• NEW runtime dependency: @eslint/core ^1.2.1, which provides the Language, TextSourceCode, and Plugin types the published declarations are built against (#30).
• NEW dev dependency: @types/node ^26.6.3, needed by the type-checked JSDoc (#30).

... (truncated)

Commits

• 2ce4e13 release: v1.0.13 - publish real types for the plugin, language and AST
• 2686e4f release: v1.0.12 - build a real ESLint AST from the jsonv parser
• 55c0ec8 release: v1.0.11 - validate language options and clean up the language…
• See full diff in compare view

Install script changes

This version adds prepare script that runs during installation. Review the package contents before updating.

Updates @cldmv/jsonv from 1.0.9 to 1.1.1

Release notes

Sourced from @​cldmv/jsonv's releases.

v1.1.1

release: v1.1.1 - include the closing } in template middle/tail tokens…

@​cldmv/jsonv v1.1.1 Changelog

Release Date: September 2026 Release Type: Patch Branch: release/1.1.1

---

Overview

Version 1.1.1 is a correctness patch on top of v1.1.0's AST/token work. Exercising the new parseToAst() output and the tolerant option surfaced nine bugs across parse-mode enforcement, tolerant-mode error reporting, reference resolution, and template-literal lexing — all fixed here, each with regression tests. Three ESLint tooling dependencies are also bumped, and CI's release-merge gate is re-armed against every check-producing workflow.

No public API changes. All v1.1.0 configuration and usage is fully compatible.

---

🐛 Bug Fixes

mode: "json" and mode: "json5" now enforce their feature sets (#65)

ParseOptions.mode was documented to restrict "json" to RFC 8259 JSON and "json5" to JSON5 1.0, but only the comment check was ever wired up — both modes silently accepted the full set of jsonv extensions (unquoted keys, single quotes, trailing commas, hex, Infinity/NaN, and, in "json5", even internal references and templates). Both modes now reject every feature outside their spec with a positioned JsonvSyntaxError naming the feature and the mode, covering every year entry point and parseToAst(). Fixes #52.

Tolerant mode reports collected syntax errors instead of a misleading reference error (#64)

With tolerant: true, parseWithOptions collected syntax errors and then evaluated the partial result anyway, so a document with real syntax errors surfaced an unrelated JsonvReferenceError ("Unresolved reference: b") instead of the errors that were actually collected. When any syntax errors are collected, parseWithOptions now throws a single JsonvAggregateSyntaxError — its own line/column/offset/code are the first error's, its message summarizes the first error plus the total count, and errors holds every collected error in source order. The document is not evaluated. Fixes #59.

Forward-reference chains of any length now resolve (#66)

Internal references resolved in a fixed number of passes, so an acyclic forward-reference chain longer than the pass limit (five or more keys) failed with a spurious "Unresolved reference" error even though nothing was circular. References now resolve by dependency order — recursively resolving a reference as soon as its target has a concrete value — instead of a fixed pass count, so chains of any depth, through member expressions and templates, resolve correctly. True cycles and self-references still throw, pointing at the reference that closes the cycle. Fixes #54.

parseToAst collects lexer errors instead of throwing (#62)

parseToAst() returns { program, comments, tokens, errors } and collected parser errors in errors, but lexer errors (unterminated templates/strings, invalid escapes, year-gated literals) were thrown instead — forcing callers to handle two separate error paths, and hiding every other error in tolerant mode behind the first lexical failure. Lexer errors are now collected into errors alongside parser errors, with the tokens lexed up to the error and a partial program returned. Fixes #51.

Template interpolations balance braces; object/array literals inside ${} are rejected clearly (#57)

While inside a template interpolation, the lexer treated the first } as the end of the interpolation, so an interpolated expression containing its own braces — an object literal, for example — broke parsing with a misleading "Expected ',' or '}'" error pointing at the wrong brace. The lexer now tracks brace depth per interpolation the way a JS lexer tracks a stack of template/brace contexts, so only the balancing } ends the interpolation; an object or array literal directly inside ${} is then explicitly rejected with a clear, correctly positioned error instead of a confusing one. Fixes #50.

Nested templates inside an interpolation now evaluate (#53)

A template literal nested inside another template's interpolation (`a${ `b${a}c` }d`) parsed with correct tokens and spans but threw JsonvReferenceError: Unresolved reference: \<template> on evaluation — reference resolution treated the inner TemplateLiteral node as a named reference instead of evaluating it. Nested templates now evaluate like any other interpolated expression, at any nesting depth, including when referencing another key or appearing inside a forward reference. Fixes #49.

Template middle/tail tokens and quasis now include the closing } (#48)

In parseToAst() output, the TemplateHead token and its quasi included the opening ${, but the } that closes an interpolation belonged to no token and no quasi — so the following TemplateMiddle/TemplateTail segment started one character too late, leaving a one-character gap in the token stream. Tokens now tile the template source with no gaps, matching ESTree/Babel/Espree conventions: a tail/middle token and its quasi start at the closing }. This shifts @cldmv/eslint-plugin-jsonv's TemplateElement ranges by one character; that plugin should be re-checked against this release. Fixes #47.

CR and CRLF in template literals normalize to LF (#56)

... (truncated)

Commits

• cbee3ca release: v1.1.1 - include the closing } in template middle/tail tokens…
• 5bfa55b release: v1.1.0 - return comments and tokens, positioned keys and…
• 4448b47 release: v1.0.10 - expose line, column and offset on parse errors
• See full diff 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 <dependency name> major version will close this group update PR and stop Dependabot creating any more for the specific dependency's major version (unless you unignore this specific dependency's major version or upgrade to it yourself)
• @dependabot ignore <dependency name> minor version will close this group update PR and stop Dependabot creating any more for the specific dependency's minor version (unless you unignore this specific dependency's minor version or upgrade to it yourself)
• @dependabot ignore <dependency name> will close this group update PR and stop Dependabot creating any more for the specific dependency (unless you unignore this specific dependency or upgrade to it yourself)
• @dependabot unignore <dependency name> will remove all of the ignore conditions of the specified dependency
• @dependabot unignore <dependency name> <ignore condition> will remove the ignore condition of the specified dependency and ignore conditions