chore(deps): update dependency polyfill to v11

[thomhurst]

This PR contains the following updates:

Package	Type	Update	Change
Polyfill	nuget	major	10.11.2 → 11.0.0

---

Release Notes

SimonCropp/Polyfill (Polyfill)

v11.0.0

Compare Source

• #​567 Retire stream-wrapper polyfills for net11
• #​568 Add Process.TryGetProcessById and silent param on Run/RunAsync

---

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 Mend Renovate.

[codacy-production]

Up to standards ✅

🟢 Issues 0 issues

Results:
0 new issues

View in Codacy

_{NEW Get contextual insights on your PRs based on Codacy's metrics, along with PR and Jira context, without leaving GitHub. Enable AI reviewer
TIP This summary will be updated as you push new changes.}

[claude]

Review: chore(deps): update dependency polyfill to v11

This is a Renovate bot PR bumping _TUnitPolyfillVersion from 10.11.2 → 11.0.0 in TUnit.Core/TUnit.Core.targets, a 1-line diff. No test/snapshot changes needed since no source-gen or public API surface is touched.

Findings

1. This is a same-day, unvetted major release — hold before merging
I checked upstream: Polyfill 11.0.0 was published to NuGet today (2026-07-14) with effectively zero download history, and there isn't even a GitHub Release/changelog entry for it yet. The commits that went into it include things like "Retire stream-wrapper polyfills for net11" and a signature change to Process.Run/RunAsync (new silent parameter). That's exactly the kind of change a major bump exists to signal, and it landed compile-time codegen used across every consumer's netstandard2.0/netstandard2.1/.NET Framework build (via TUnit.Core.targets's auto-injection). A regression here doesn't just affect TUnit's own build — it breaks builds for every downstream TUnit consumer on those TFMs.

Suggest: don't merge until CI is green (currently all pending) and ideally not until the package has had a few days of community exposure. Longer-term, consider adding a minimumReleaseAge (e.g. 3-7 days, larger for majors) to renovate.json. Right now there's no such setting, which is why Renovate opened this same-day. That's a cheap, durable fix — it doesn't just help this PR, it protects every future Polyfill/major bump from the same risk.

2. This bump only touches one of the repo's Polyfill version references, leaving them inconsistent
Directory.Packages.props:81 still pins Polyfill to 10.11.2 via CPM. That version isn't overridden the way TUnit.Core.targets does for its own auto-injected reference — it's what's actually resolved for the plain <PackageReference Include="Polyfill" /> entries in tools/tunit-nuget-tester/**/*.csproj. After this PR merges, TUnit's externally-injected Polyfill version and its own internal tooling's Polyfill version diverge (11.0.0 vs 10.11.2). Separately, TUnit.Templates/content/TUnit/TestProject.csproj:17 also hardcodes 10.11.2 and wasn't touched.

This isn't a blocker for this specific PR (Renovate raised it correctly for the property it found), but it's worth fixing the underlying config gap: add a Renovate packageRules group keyed on the Polyfill package name/pattern across all three locations (Directory.Packages.props, TUnit.Core.targets, and the template .csproj) so future bumps land as one atomic, consistent PR instead of silently drifting. Right now there's no packageRules in renovate.json at all, so nothing enforces this.

Verdict

Mechanically the diff is correct and minimal. The concerns above are about when to merge and a config gap that let this PR only cover one of three places Polyfill's version is pinned — not about anything wrong with the line that changed. I'd wait for CI to go green and give the fresh major release a short cooldown before merging, then follow up on the Renovate config so this doesn't recur.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: e37e90012a

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Do not force Polyfill 11 onto downlevel consumers

For netstandard/.NET Framework projects that do not explicitly reference Polyfill, this target now silently injects Polyfill 11.0.0 into their compilation. Polyfill 11 changes the downlevel Process.Run/RunAsync string overloads by inserting a bool silent parameter before the existing timeout/cancellation parameter, so existing TUnit consumers that compile today with the auto-injected 10.x source and call those overloads positionally (for example passing a TimeSpan or CancellationToken as the third argument) will fail to compile or bind differently just by upgrading TUnit. Since this is a hidden transitive source package rather than an explicit user dependency, keep the auto-injected version on the 10.x line unless TUnit is intentionally shipping that source-breaking change.

Useful? React with 👍 / 👎.

[claude]

Code review

No issues found. This is a trivial, correct dependency bump: _TUnitPolyfillVersion in TUnit.Core/TUnit.Core.targets goes from 10.11.2 → 11.0.0, consistent with the Polyfill version already pinned in Directory.Packages.props and TUnit.Templates/content/TUnit/TestProject.csproj. No stale 10.11.2 references remain anywhere in the repo. Checked for bugs and CLAUDE.md compliance.

[claude]

Code review

No issues found. This remains a minimal, correct dependency bump: _TUnitPolyfillVersion in TUnit.Core/TUnit.Core.targets goes from 10.11.2 → 11.0.0.

Re-checked the inconsistency flagged in an earlier review comment on this PR (Directory.Packages.props and TUnit.Templates/content/TUnit/TestProject.csproj still pinning 10.11.2) — that's now resolved on main, which this PR is based on: both files already resolve to Polyfill 11.0.0, so all three Polyfill version references in the repo are consistent after this merges. No stale 10.11.2 references remain.

CI checks are still in progress (no failures so far); recommend waiting for them to go green before merging. Checked for bugs and CLAUDE.md compliance.