chore(deps): bump cspell from 10.0.1 to 10.1.0

[dependabot]

Bumps cspell from 10.0.1 to 10.1.0.

Release notes

Sourced from cspell's releases.

v10.1.0

Features

feat(cspell-junit-reporter): add JUnit XML reporter package (#8945)

Closes #4570.

Adds @cspell/cspell-junit-reporter, a new workspace package modeled on packages/cspell-json-reporter, that emits a JUnit-compatible XML report of a cspell run.

The issue asked for a minimal mapping along the lines of:

<testsuite tests="3">
  <testcase classname="File1" name"/>
  <testcase classname="File2" name="AnotherSuccessfulTest"/>
  <testcase classname="foo3" name="AFailingTest">
    <failure type="prohibited word"> zzz </failure>
  </testcase>
</testsuite>

This PR follows that shape but wraps it in a <testsuites> root and groups by file (one <testsuite> per file, suite name = file path), since that is the convention used by other widely-consumed JUnit reporters (for example ESLint's JUnit formatter) and is what most CI JUnit parsers expect. The package README documents the full mapping.

• package.json, tsconfig.json, test framework, and files/exports/publishConfig shape are copied from cspell-json-reporter. Version pinned to 10.0.1 to match the monorepo's locked versioning.
• No third-party XML library was added. The repo has no existing XML dependency, so a small escaping helper (src/utils/escapeXml.ts) and a pure XML-string builder (src/utils/buildJUnitXml.ts) were written in-repo, consistent with the monorepo's small-utility-file convention.
• Unit tests (32) cover: no files, a clean file (single passing testcase), a file with issues, escaping of special characters in paths/words/messages, a skipped file, and non-issue processing errors (error emitter routed to a dedicated cspell-errors testsuite using <error>).

Assumptions the issue thread left ambiguous, called out for review:

1. One <testsuite> per file rather than one flat suite for the whole run. Matches common JUnit reporter convention and keeps per-file counts meaningful in CI UIs.
2. A clean file gets one synthetic passing <testcase name="no issues found"> so a suite is never reported with tests="0", which some JUnit consumers treat as suspicious.
3. Settings are intentionally slimmer than cspell-json-reporter's (outFile, suiteName only). JUnit XML has no natural place for arbitrary debug/progress log dumps.
4. cspell processing errors are reported as <error> elements, distinct from spelling <failure> elements, per the JUnit failure-vs-error distinction.

Verified locally: tsc -b clean, vitest 32/32, eslint and prettier clean, and the full monorepo build:prod succeeds with the package in the workspace. One environment note: the package's CLI smoke-test script wasn't runnable locally (repo requires Node >=22.18.0, local was 22.17.0 — the sibling json-reporter fails identically there), so CI is the first place it will run.

---

Fixes

fix: allow substitutions across ignored ranges (#9017)

... (truncated)

Changelog

Sourced from cspell's changelog.

v10.1.0 (2026-08-22)

Features

feat(cspell-junit-reporter): add JUnit XML reporter package (#8945)

Closes #4570.

Adds @cspell/cspell-junit-reporter, a new workspace package modeled on packages/cspell-json-reporter, that emits a JUnit-compatible XML report of a cspell run.

The issue asked for a minimal mapping along the lines of:

<testsuite tests="3">
  <testcase classname="File1" name"/>
  <testcase classname="File2" name="AnotherSuccessfulTest"/>
  <testcase classname="foo3" name="AFailingTest">
    <failure type="prohibited word"> zzz </failure>
  </testcase>
</testsuite>

This PR follows that shape but wraps it in a <testsuites> root and groups by file (one <testsuite> per file, suite name = file path), since that is the convention used by other widely-consumed JUnit reporters (for example ESLint's JUnit formatter) and is what most CI JUnit parsers expect. The package README documents the full mapping.

• package.json, tsconfig.json, test framework, and files/exports/publishConfig shape are copied from cspell-json-reporter. Version pinned to 10.0.1 to match the monorepo's locked versioning.
• No third-party XML library was added. The repo has no existing XML dependency, so a small escaping helper (src/utils/escapeXml.ts) and a pure XML-string builder (src/utils/buildJUnitXml.ts) were written in-repo, consistent with the monorepo's small-utility-file convention.
• Unit tests (32) cover: no files, a clean file (single passing testcase), a file with issues, escaping of special characters in paths/words/messages, a skipped file, and non-issue processing errors (error emitter routed to a dedicated cspell-errors testsuite using <error>).

Assumptions the issue thread left ambiguous, called out for review:

1. One <testsuite> per file rather than one flat suite for the whole run. Matches common JUnit reporter convention and keeps per-file counts meaningful in CI UIs.
2. A clean file gets one synthetic passing <testcase name="no issues found"> so a suite is never reported with tests="0", which some JUnit consumers treat as suspicious.
3. Settings are intentionally slimmer than cspell-json-reporter's (outFile, suiteName only). JUnit XML has no natural place for arbitrary debug/progress log dumps.
4. cspell processing errors are reported as <error> elements, distinct from spelling <failure> elements, per the JUnit failure-vs-error distinction.

Verified locally: tsc -b clean, vitest 32/32, eslint and prettier clean, and the full monorepo build:prod succeeds with the package in the workspace. One environment note: the package's CLI smoke-test script wasn't runnable locally (repo requires Node >=22.18.0, local was 22.17.0 — the sibling json-reporter fails identically there), so CI is the first place it will run.

---

Fixes

fix: allow substitutions across ignored ranges (#9017)

... (truncated)

Commits

• 401518c v10.1.0
• acf8449 chore: Prepare Release v10.1.0 (auto-deploy) (#8883)
• 3078371 fix: Workflow Bot -- Update Dictionaries (main) (#9024)
• f557824 ci: Workflow Bot -- Update ALL Dependencies (main) (#9014)
• 1c11da6 ci: Workflow Bot -- Update ALL Dependencies (main) (#8970)
• 67448c8 chore: bump the development-dependencies group across 1 directory with 16 upd...
• ce30dc7 chore: bump chalk from 5.6.2 to 6.0.0 (#8973)
• 9703748 ci: Workflow Bot -- Update ALL Dependencies (main) (#8952)
• c8b94a7 doc: Update Node version requirement to 22 (#8940)
• 69c4b7f chore: bump commander from 14.0.3 to 15.0.0 (#8925)
• 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)

[pkg-pr-new]

Open in StackBlitz

npm i https://pkg.pr.new/openworkflowdev/openworkflow/@openworkflow/cli@708

npm i https://pkg.pr.new/openworkflowdev/openworkflow/@openworkflow/dashboard@708

npm i https://pkg.pr.new/openworkflowdev/openworkflow@708

commit: 497526a

[dependabot]

Superseded by #719.