chore(deps): bump xerces-wasm from 1.0.0 to 2.0.1 in the production-dependencies group

[dependabot]

Bumps the production-dependencies group with 1 update: xerces-wasm.

Updates xerces-wasm from 1.0.0 to 2.0.1

Release notes

Sourced from xerces-wasm's releases.

v2.0.0 — Full rewrite: cached grammar pools

⚠️ Breaking release. v2 is a complete rewrite with a new architecture and API. v1.x code will not work unchanged — see Migration below.

Highlights

• In-memory grammar pool caching — each project's XSDs compile once into a locked XMLGrammarPool held in WASM memory; every validation reuses it, no re-parsing.
• New project-based API — createProjectValidator() returns a reusable validator with validate(), reload(), and destroy().
• Per-project isolation — each project keeps its own compiled pool, so the same XML can be valid in one project and invalid in another.
• Fast re-validation — in the bundled benchmark: ~22 ms one-time compile, ~0.04 ms per subsequent validate().
• Node.js + browser — the same WASM module runs in both.

New API

import { createProjectValidator } from "xerces-wasm";
const v = await createProjectValidator({
entry: "main.xsd",
files: { "main.xsd": xsdText /*, "types.xsd": ... */ },
});
const { valid, parseErrors, schemaErrors } = await v.validate(xml);
await v.reload(updatedFiles); // recompile when schemas change
v.destroy();                  // free the pool from WASM memory

Every validate() runs two passes: syntax (well-formedness → parseErrors) and schema (XSD rules → schemaErrors). Diagnostics are { message, line, column, severity }.

Breaking changes

• Validation now goes through a createProjectValidator() instance, not a one-shot top-level call.
• Results are { valid, parseErrors, schemaErrors } (separate syntax vs. schema error lists).
• You must call destroy() when done — WASM memory is not reclaimed by the JS garbage collector.

Migration from v1.x

1. Create one validator per project with createProjectValidator({ entry, files }).
2. Pass every dependent XSD in files (keyed by filename) so xs:import / xs:include resolve from memory.
3. Read results from parseErrors / schemaErrors instead of the old result shape.
4. Call destroy() when a project closes.

Install

npm install xerces-wasm@2.0.0

License

MIT. Bundles Apache Xerces-C++ (Apache-2.0) — see LICENSE-APACHE and NOTICE.

Changelog

Sourced from xerces-wasm's changelog.

Changelog

All notable changes to this project are documented here. The format is based on Keep a Changelog, and this project adheres to Semantic Versioning.

[2.0.0] - 2026-06-24

Full rewrite. v2 is a complete re-architecture with a new API — v1.x code will not work unchanged. See Migration below.

Added

• createProjectValidator() — a reusable, per-project validator backed by an in-memory grammar pool.
• In-memory XSD caching: each project's schemas compile once into a locked XMLGrammarPool held in WASM memory and are reused on every validation.
• Per-project isolation — each project keeps its own compiled pool, so the same XML can be valid in one project and invalid in another.
• Two-pass validation results: parseErrors (well-formedness) and schemaErrors (XSD rules), each as { message, line, column, severity }.
• reload() to recompile a project's pool when schemas change, and destroy() to free WASM memory.
• Bundled Apache Xerces-C++ license (LICENSE-APACHE) and NOTICE.

Changed

• Breaking: validation now goes through a createProjectValidator() instance instead of a one-shot top-level call.
• Breaking: result shape is now { valid, parseErrors, schemaErrors }.

Performance

• After a one-time compile (~22 ms in the bundled benchmark), repeat validations run in ~0.04 ms.

Migration

1. Create one validator per project: createProjectValidator({ entry, files }).
2. Pass all dependent XSDs in files (keyed by filename) so xs:import / xs:include resolve from memory.
3. Read results from parseErrors / schemaErrors.
4. Call destroy() when a project closes — WASM memory is not reclaimed by the JS GC.

Commits

• 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