fix: correct engines.node to match vite/rolldown's actual requirement

[jfhenon]

Summary

• Fixes svgedit doesn't build (SyntaxError: The requested module 'node:util' does not provide an export named 'styleText') #1102 — build fails with SyntaxError: The requested module 'node:util' does not provide an export named 'styleText'
• Root cause: vite@8/rolldown require Node ^20.19.0 || >=22.12.0 (confirmed in their own package.json engines fields — they use node:util's styleText, which isn't available on earlier Node 20.x, 21.x, or early 22.x releases). Our root package.json only required >=20, so unsupported versions (e.g. Node 21.0.0, as in the reporter's Docker repro) passed the engine check and only failed later with a confusing low-level rolldown crash.
• Corrected engines.node to ^20.19.0 || >=22.12.0 and regenerated the lockfile to match.
• Added .npmrc with engine-strict=true so npm install now fails fast with a clear "Unsupported engine" message on an incompatible Node version, instead of letting the build fail later with a cryptic error.

Test plan

• npm install succeeds on Node v24.18.0 (satisfies the new range)
• npm run build --workspace @svgedit/svgcanvas builds successfully
• Verified vite/rolldown's own engines fields in node_modules to confirm the correct minimum version range

🤖 Generated with Claude Code

Summary by Sourcery

Tighten Node.js engine requirements to align with vite/rolldown and enforce early failure on unsupported Node versions.

Build:

• Update root package.json Node engine range to ^20.19.0 || >=22.12.0 to match vite/rolldown requirements.
• Regenerate package-lock.json to reflect the updated engine constraints and dependency resolution.
• Add an .npmrc with engine-strict=true so npm install fails fast on incompatible Node versions.

[sourcery-ai]

Reviewer's guide (collapsed on small PRs)

Reviewer's Guide

Updates the Node engine requirement to align with vite/rolldown’s actual minimum versions and enforces engine checks at install time, with the lockfile regenerated accordingly.

Sequence diagram for npm install and build with strict Node engine enforcement

sequenceDiagram
    actor Developer
    participant npm
    participant Node
    participant Project

    Developer->>npm: npm install
    npm->>Project: read package.json engines.node
    npm->>Node: check version satisfies ^20.19.0 || >=22.12.0
    alt compatible_version
        npm-->>Developer: install succeeds
        Developer->>npm: npm run build --workspace @svgedit/svgcanvas
        npm->>Project: invoke vite/rolldown build
        Project->>Node: use util.styleText
        Node-->>Project: styleText available
    else incompatible_version
        npm-->>Developer: fail install with Unsupported engine (engine-strict)
    end

Loading

File-Level Changes

Change	Details	Files
Tightened Node engine version range to match vite/rolldown requirements and regenerated dependencies metadata.	Updated the root package.json engines.node field from a broad ">=20" range to "^20.19.0
Enforced strict engine checks during npm installations to fail fast on incompatible Node versions.	Added an .npmrc configuration file enabling engine-strict so npm install aborts with an explicit unsupported engine error on mismatched Node versions.	.npmrc

Assessment against linked issues

Issue	Objective	Addressed	Explanation
#1102	Update the project’s Node.js version requirement so that only versions compatible with vite/rolldown (and providing node:util.styleText) are allowed, preventing the build-time SyntaxError.	✅
#1102	Enforce and surface the Node.js engine requirement during installation so users following the build instructions receive a clear error on incompatible Node versions instead of a cryptic build failure.	✅

Possibly linked issues

• svgedit doesn't build (SyntaxError: The requested module 'node:util' does not provide an export named 'styleText') #1102: PR tightens Node engine version and adds engine-strict, directly preventing the build failure reported in the issue.

---

Tips and commands

Interacting with Sourcery

• Trigger a new review: Comment @sourcery-ai review on the pull request.
• Continue discussions: Reply directly to Sourcery's review comments.
• Generate a GitHub issue from a review comment: Ask Sourcery to create an
  issue from a review comment by replying to it. You can also reply to a
  review comment with @sourcery-ai issue to create an issue from it.
• Generate a pull request title: Write @sourcery-ai anywhere in the pull
  request title to generate a title at any time. You can also comment
  @sourcery-ai title on the pull request to (re-)generate the title at any time.
• Generate a pull request summary: Write @sourcery-ai summary anywhere in
  the pull request body to generate a PR summary at any time exactly where you
  want it. You can also comment @sourcery-ai summary on the pull request to
  (re-)generate the summary at any time.
• Generate reviewer's guide: Comment @sourcery-ai guide on the pull
  request to (re-)generate the reviewer's guide at any time.
• Resolve all Sourcery comments: Comment @sourcery-ai resolve on the
  pull request to resolve all Sourcery comments. Useful if you've already
  addressed all the comments and don't want to see them anymore.
• Dismiss all Sourcery reviews: Comment @sourcery-ai dismiss on the pull
  request to dismiss all existing Sourcery reviews. Especially useful if you
  want to start fresh with a new review - don't forget to comment
  @sourcery-ai review to trigger a new review!

Customizing Your Experience

Access your dashboard to:

• Enable or disable review features such as the Sourcery-generated pull request
  summary, the reviewer's guide, and others.
• Change the review language.
• Add, remove or edit custom review instructions.
• Adjust other review settings.

Getting Help

• Contact our support team for questions or feedback.
• Visit our documentation for detailed guides and information.
• Keep in touch with the Sourcery team by following us on X/Twitter, LinkedIn or GitHub.

[sourcery-ai]

Hey - I've left some high level feedback:

• Since .npmrc with engine-strict=true only affects npm, consider mirroring this constraint in other package managers’ configs (e.g., pnpm/Yarn) if they’re used in the project to avoid inconsistent behavior across tooling.
• If any workspace packages are published or used independently, you may want to align their individual engines.node fields with the root setting so consumers see the same minimum Node requirements everywhere.

Prompt for AI Agents

Please address the comments from this code review:

## Overall Comments
- Since `.npmrc` with `engine-strict=true` only affects npm, consider mirroring this constraint in other package managers’ configs (e.g., pnpm/Yarn) if they’re used in the project to avoid inconsistent behavior across tooling.
- If any workspace packages are published or used independently, you may want to align their individual `engines.node` fields with the root setting so consumers see the same minimum Node requirements everywhere.

---

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

• X
• Mastodon
• LinkedIn
• Facebook

_{Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.}

[jfhenon]

Addressed both points:

• pnpm/Yarn: checked — this repo only uses npm (no `yarn.lock`, `pnpm-lock.yaml`, `.yarnrc*`, or `packageManager` field, and no workflow references those tools), so there's nothing to mirror `engine-strict` in. Also worth noting: `engine-strict` itself was already reverted from this PR in a prior commit — it surfaced an unrelated pre-existing mismatch (`open-cli` requiring Node ≥22) that broke CI on the Node 20.x runners, which is out of scope for this fix.
• Workspace packages: `@svgedit/svgcanvas` and `@svgedit/react-test` are both published independently (`publishConfig.access: public`), but neither declared its own `engines` field. Added the same `engines.node` range to both so consumers installing them directly see the accurate minimum Node requirement.