chore(deps): update dependency path-to-regexp to v0.2.5

[thomhurst]

This PR contains the following updates:

Package	Type	Update	Change
path-to-regexp	resolutions	minor	0.1.13 → 0.2.5

---

Release Notes

pillarjs/path-to-regexp (path-to-regexp)

v0.2.5

Compare Source

• Allow keys parameter to be omitted

v0.2.4

Compare Source

• Code coverage badge
• Updated readme
• Attach keys to the generated regexp

v0.2.3

Compare Source

• Add MIT license

v0.2.2

Compare Source

• A passed in trailing slash in non-strict mode will become optional
• In non-end mode, the optional trailing slash will only match at the end

v0.2.1

Compare Source

• Fixed a major capturing group regexp regression

v0.2.0

Compare Source

• Improved support for arrays
• Improved support for regexps
• Better support for non-ending strict mode matches with a trailing slash
• Travis CI support
• Block using regexp special characters in the path
• Removed support for the asterisk to match all
• New support for parameter suffixes - *, + and ?
• Updated readme
• Provide delimiter information with keys array

---

Configuration

📅 Schedule: (UTC)

• Branch creation
  • At any time (no schedule defined)
• Automerge
  • At any time (no schedule defined)

🚦 Automerge: Enabled.

♻ Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

---

• If you want to rebase/retry this PR, check this box

---

This PR has been generated by Renovate Bot.

[claude]

PR Review: chore(deps): update dependency path-to-regexp to v0.2.5

This is a Renovate Bot dependency update for the docs site's npm dependencies. The change is straightforward and limited in scope.

Summary of changes:

• Bumps resolution override in docs/package.json from 0.1.13 to 0.2.5
• Updates docs/yarn.lock to reflect the new resolved version
• Importantly, the yarn.lock correctly preserves the 0.1.13 entry for packages that depend on the ~0.1.12 range (e.g., express), while the express/path-to-regexp resolution override now points to 0.2.5

Assessment:

This is a security/maintenance update to the docs site's JavaScript tooling only. It has no impact on:

• The TUnit core engine or test execution logic
• Source generator or reflection modes
• Native AOT compatibility
• The Microsoft.Testing.Platform integration

The yarn.lock change looks correct — the path-to-regexp@~0.1.12 entry is retained as a separate block for packages that still require that semver range, while the explicit path-to-regexp@0.2.5 block is added for the resolution override. This avoids breaking transitive dependents that rely on the older version.

One minor observation: The version jump from 0.1.x to 0.2.x is a minor bump but does include a breaking change noted in the release notes: removal of asterisk wildcard support and changes to how arrays/regexps are handled. Since this is only a resolution override for the docs site tooling (not a direct runtime dependency of TUnit itself), the risk is very low. However, it would be worth confirming that the docs build (cd docs && yarn build or equivalent) still succeeds after this change.

Overall, this looks like a safe, routine dependency update. No concerns from a TUnit framework perspective.

[claude]

PR Review: chore(deps): update dependency path-to-regexp to v0.2.5

This is a Renovate Bot dependency update for the docs site's npm dependencies. The change is straightforward and limited in scope.

Summary of changes:

• Bumps the path-to-regexp resolution override in docs/package.json from 0.1.13 to 0.2.5
• Updates docs/yarn.lock to reflect the new resolved version
• The yarn.lock correctly preserves the 0.1.13 entry for packages that still require the ~0.1.12 semver range (e.g., express internals), while adding a separate 0.2.5 block for the explicit resolution override

Assessment:

This is a maintenance/security update scoped entirely to the docs site JavaScript tooling. It has no impact on:

• The TUnit core engine or test execution logic
• Source generator or reflection modes
• Native AOT compatibility
• The Microsoft.Testing.Platform integration

The yarn.lock change is correct — the path-to-regexp@~0.1.12 entry is retained as a separate block for transitive dependents that still require that range, while the new path-to-regexp@0.2.5 block is added for the resolution pin. This correctly avoids breaking those transitive dependents.

Minor observation: The jump from 0.1.x to 0.2.x includes some breaking changes per the release notes (removal of asterisk wildcard, changes to array/regexp handling). Since this is only a resolution override for docs tooling and not a direct runtime dependency of TUnit itself, the risk is very low. That said, it would be worth confirming the docs site still builds successfully after this bump (e.g., cd docs && yarn build).

Overall, this looks like a safe and routine dependency update with no concerns from a TUnit framework perspective.

[codacy-production]

Up to standards ✅

🟢 Issues0 issues

Results:
0 new issues

View in Codacy

_{TIP This summary will be updated as you push new changes. Give us feedback}

[claude]

Review: chore(deps): update dependency path-to-regexp to v0.2.5

This is a routine Renovate Bot dependency update scoped entirely to the docs site JavaScript tooling (docs/package.json and docs/yarn.lock). It has no impact on TUnit's core framework, source generator, reflection engine, AOT compatibility, or Microsoft.Testing.Platform integration.

Changes look correct:

• The resolution override in docs/package.json is bumped from 0.1.13 to 0.2.5
• The yarn.lock correctly splits the entry into two blocks: a new 0.2.5 block for the explicit resolution pin, and a retained 0.1.13 block for packages still requiring the ~0.1.12 semver range (e.g., transitive express dependencies)

One note: The 0.1.x to 0.2.x jump does include breaking changes (asterisk wildcard removed, array/regexp handling changes), but since this is only a resolution override for docs tooling, the risk is minimal. Verifying that the docs site still builds after this change would be a prudent final check.

No concerns from a TUnit framework perspective. Safe to merge.