Bump flatted from 3.3.3 to 3.4.2 in /dotnet/samples/Demos/ProcessFrameworkWithSignalR/src/ProcessFramework.Aspire.SignalR.ReactFrontend

[dependabot]

Bumps flatted from 3.3.3 to 3.4.2.

Commits

• 3bf0909 3.4.2
• 885ddcc fix CWE-1321
• 0bdba70 added flatted-view to the benchmark
• 2a02dce 3.4.1
• fba4e8f Merge pull request #89 from WebReflection/python-fix
• 5fe8648 added "when in Rome" also a test for PHP
• 53517ad some minor improvement
• b3e2a0c Fixing recursion issue in Python too
• c4b46db Add SECURITY.md for security policy and reporting
• f86d071 Create dependabot.yml for version updates
• Additional commits viewable 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 this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
  You can disable automated security fix PRs for this repo from the Security Alerts page.

[github-actions]

Automated Code Review

Reviewers: 4 | Confidence: 92%

✓ Correctness

This PR only modifies auto-generated lockfiles (package-lock.json and yarn.lock). The changes remove 'peer: true' flags from packages that are direct or dev dependencies in package.json (react, react-dom, @fluentui/react-components, @types/react, @types/react-dom, typescript, eslint, vite, etc.), which is correct. The only version change is flated 3.3 → 3.4.2, a patch-level bump of a transitive dev dependency. No correctness issues found.

✓ Security Reliability

This PR updates lockfiles (package-lock.json and yarn.lock) for a React frontend sample app. The changes are: (1) removing "peer": true flags from numerous packages, which means these packages are now treated as direct/transitive dependencies rather than peer dependencies — this is consistent with them already being listed in package.json's dependencies/devDependencies, and (2) bumping flatted from 3.3.3 to 3.4.2, a minor version update of a dev dependency used by flat-cache/eslint. No security or reliability concerns identified. The integrity hashes are present and match the expected format for the declared versions. No new dependencies are introduced, no secrets are exposed, and no code changes are involved.

✓ Test Coverage

This PR modifies only lockfiles (package-lock.json and yarn.lock) for a React frontend demo sample. The changes remove "peer": true flags from numerous dependencies (promoting them from peer to direct/transitive dependencies) and bump flated from 3.3.3 to 3.4.2. These are purely dependency metadata changes in lockfiles within a demo/sample project — no application code, library code, or test code is added or modified. There is no new or changed behavior that would require test coverage.

✓ Design Approach

This PR is a lockfile-only update: it removes stale "peer": true annotations from packages that are explicitly listed as direct dependencies in package.json (react, react-dom, @fluentui/react-components, @types/react, @types/react-dom, etc.), and bumps flatted from 3.3.3 → 3.4.2 in both lock files. The "peer": true removals are correct — those packages genuinely belong to dependencies/devDependencies in package.json, so npm should not mark them as peer-only. The flatted bump is a minor dev-dependency patch. One pre-existing structural concern (not introduced by this PR): the project maintains both package-lock.json and yarn.lock simultaneously, which means the two lock files can diverge silently depending on which package manager CI or developers happen to run. This PR's yarn.lock and package-lock.json updates are consistent with each other, so it does not make the divergence problem worse, but the root cause remains unaddressed.

Suggestions

• The project ships both package-lock.json and yarn.lock. Relying on two competing lock files is a latent correctness risk — whichever package manager a developer or CI pipeline uses may produce different installs. Consider picking one (npm or yarn) and removing the other lock file to eliminate this ambiguity.

---

Automated review by dependabot[bot]'s agents