chore(deps): update dependency polyfill to 11.2.0

[thomhurst]

This PR contains the following updates:

Package	Type	Update	Change
Polyfill	nuget	minor	11.0.2 → 11.2.0

---

Release Notes

SimonCropp/Polyfill (Polyfill)

v11.2.0

Compare Source

---

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 CLI.

[greptile-apps]

Greptile Summary

Updates Polyfill from 11.0.2 to 11.2.0 for centrally managed repository dependencies and generated .NET Framework test projects.

• Bumps the central Polyfill package version.
• Aligns the TUnit project template’s explicit Polyfill reference.

Confidence Score: 5/5

The PR appears safe to merge.

No blocking failure remains.

Important Files Changed

Filename	Overview
Directory.Packages.props	Updates the centrally managed Polyfill dependency from 11.0.2 to 11.2.0.
src/TUnit.Templates/content/TUnit/TestProject.csproj	Updates the Polyfill reference emitted for generated .NET Framework test projects to 11.2.0.

_{Reviews (2): Last reviewed commit: "chore(deps): update dependency polyfill ..." | Re-trigger Greptile}

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 5b014d6292

ℹ️ 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]

Keep the packaged automatic Polyfill version in sync

For consumers targeting .NET Framework or netstandard2.x without their own Polyfill reference, the packaged src/TUnit.Core/TUnit.Core.targets still sets _TUnitPolyfillVersion to 11.0.2 and injects that value through either Version or VersionOverride. Consequently, this update affects repository builds and generated templates but leaves TUnit's automatic dependency path on the old release; update the packaged target's version alongside this central version.

Useful? React with 👍 / 👎.

[claude]

Code review

Reviewed this Polyfill 11.0.2 → 11.2.0 dependency bump. One issue found — the update is incomplete.

Issue: Polyfill version bump doesn't propagate to the shipped package injection mechanism

This PR updates Directory.Packages.props and src/TUnit.Templates/content/TUnit/TestProject.csproj to Polyfill 11.2.0, but leaves _TUnitPolyfillVersion unchanged at 11.0.2 here:

TUnit/src/TUnit.Core/TUnit.Core.targets

Lines 9 to 13 in 5b014d6

	<!-- Auto-include Polyfill package for compile-time type generation -->
	<PropertyGroup>
	<_TUnitPolyfillVersion>11.0.2</_TUnitPolyfillVersion>
	<_TUnitNeedsPolyfill Condition="'$(TargetFramework)' == 'netstandard2.0' or '$(TargetFramework)' == 'netstandard2.1' or '$(TargetFrameworkIdentifier)' == '.NETFramework'">true</_TUnitNeedsPolyfill>
	</PropertyGroup>

That property drives the PackageReferences a few lines below (both the non-CPM and CPM/VersionOverride branches) which auto-inject Polyfill into downstream consumers' netstandard2.0/netstandard2.1/.NET Framework projects when they reference TUnit.Core. Since this value is hardcoded independently of Directory.Packages.props (it has to be — it's baked into the shipped .targets file, not resolved via the repo's own CPM), bumping the central package version doesn't actually change what gets pushed onto consumers. As it stands, this PR's stated goal — moving to Polyfill 11.2.0 — is only achieved for TUnit's own build, not for the packages TUnit ships.

Why this matters architecturally: the duplication between Directory.Packages.props and _TUnitPolyfillVersion is a structural landmine — any future automated or manual Polyfill bump can silently repeat this miss, since nothing ties the two together or fails the build if they diverge. Two ways to close that gap:

• Add a lightweight CI/test check (or an MSBuild assertion) that fails if _TUnitPolyfillVersion in TUnit.Core.targets doesn't match the Polyfill PackageVersion in Directory.Packages.props, so drift is caught at PR time instead of relying on manual review.
• Alternatively, have TUnit.Core.targets read the version from a single shared property (e.g. an MSBuild .props file imported by both the repo build and packed into the .targets) rather than hardcoding it twice.

Given Renovate can't know about this internal duplication, _TUnitPolyfillVersion should be bumped to 11.2.0 manually as part of this PR (or a follow-up) before merging.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 901c1f0a-2896-41ef-aa39-6d5b84228814

📥 Commits

Reviewing files that changed from the base of the PR and between 6c5eb65 and 7306389.

📒 Files selected for processing (2)

• Directory.Packages.props
• src/TUnit.Templates/content/TUnit/TestProject.csproj

---

📝 Walkthrough

Walkthrough

The pull request updates Polyfill from version 11.0.2 to 11.2.0 in central package management and the TUnit template project.

Changes

Polyfill version update

Layer / File(s)	Summary
Update Polyfill references Directory.Packages.props, src/TUnit.Templates/content/TUnit/TestProject.csproj	The centrally managed package version and conditional template reference now use Polyfill 11.2.0.

Estimated code review effort: 1 (Trivial) | ~2 minutes

Poem

A rabbit checks the package line,
“Eleven-two-oh looks fine!”
The template hops along,
With updated code so strong,
And version bumps in tidy time.

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly and concisely describes the Polyfill dependency update from the changeset.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch renovate/polyfill-11.x

---

_{Comment @coderabbitai help to get the list of available commands.}

[claude]

Code review

Reviewed this Polyfill 11.0.2 → 11.2.0 dependency bump.

Follow-up on my previous comment: the _TUnitPolyfillVersion property in TUnit.Core.targets now matches 11.2.0, so the version is consistent across Directory.Packages.props, the template's TestProject.csproj, and the injected-package mechanism for downstream consumers. I didn't find any other stale 11.0.2 references in the repo.

No issues found. Checked for bugs and CLAUDE.md compliance.

The structural suggestion from my earlier review still stands as a nice-to-have for the future: nothing currently ties _TUnitPolyfillVersion to the Directory.Packages.props entry, so a future Renovate bump could silently miss the .targets file again unless someone manually catches it (as happened here). Worth a follow-up to derive one from the other, or add a CI check that fails on drift — but that's out of scope for this dependency bump and not blocking.