chore: upgrade tmp >= 0.2.6 where possible [Lightspeed] [release-1.10]

[Omar-AlJaljuli]

Hey, I just made a Pull Request!

Although tmp is a transitive dep of a devDep, it is in the SBOMs and has a vulnerability CVE-2026-44705. Fix by upgrading to tmp version > 0.2.5. This couldn't be upgraded under @changesets/cli@2.27.9, but that is a devDependency so it's no problem.

Upgrade using 'yarn up -R ...'.

✔️ Checklist

• A changeset describing the change and affected packages. (more info)
• Added or Updated documentation
• Tests for new functionality and regression tests for bug fixes
• Screenshots attached (for UI changes)

[rhdh-qodo-merge]

PR Summary by Qodo

Upgrade transitive tmp to 0.2.7 to address CVE-2026-44705

🐞 Bug fix ⚙️ Configuration changes 🕐 Less than 10 minutes

AI Description

• Bumps transitive dependency tmp from 0.2.5 to 0.2.7 in Lightspeed workspace lockfile.
• Mitigates CVE-2026-44705 exposure in generated SBOMs without changing runtime code.

High-Level Assessment

The following are alternative approaches to this PR:

1. Use Yarn resolutions/overrides for tmp

• ➕ Forces the secure tmp version across the whole workspace even if upstream constraints change
• ➕ Makes intent explicit in package.json rather than only in yarn.lock
• ➖ Adds ongoing maintenance burden and potential for version conflicts
• ➖ May mask upstream dependency constraints and lead to harder upgrades later

2. Upgrade/replace the upstream devDependency pulling tmp

• ➕ Removes the vulnerable transitive source at the root
• ➕ Often reduces the need for lockfile pinning/resolutions
• ➖ May be blocked by upstream constraints (as noted with @changesets/cli)
• ➖ Potentially larger change with more churn and review surface

Recommendation: Current approach (lockfile update via yarn up -R) is appropriate given this is a transitive devDep and upstream constraints block a clean upgrade path. If this recurs or spreads across workspaces, consider adding an explicit Yarn resolution to make the security intent resilient to future lock regenerations.

Files changed (1) +3 / -3

Other (1) +3 / -3

yarn.lockBump tmp from 0.2.5 to 0.2.7 in lockfile +3/-3

Bump tmp from 0.2.5 to 0.2.7 in lockfile

• Updates the locked version, resolution, and checksum for tmp (npm:^0.2.5) to resolve to 0.2.7. This is a dependency-only change intended to address a reported vulnerability affecting SBOM output.

workspaces/lightspeed/yarn.lock

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[rhdh-qodo-merge]

Code Review by Qodo

🐞 Bugs (1) 📘 Rule violations (0) 🔗 Cross-repo conflicts (0) 📜 Skill insights (0)

1. Repo tmp bump incomplete 🐞 Bug ⛨ Security

Description

The PR upgrades tmp@^0.2.5 only in workspaces/lightspeed/yarn.lock, while other workspace
lockfiles still resolve tmp@^0.2.5 to 0.2.5. If vulnerability scanning or SBOM generation covers
those workspaces, this PR won’t fully address the tmp upgrade objective.

Code

workspaces/lightspeed/yarn.lock[R35174-35176]

+  version: 0.2.7
+  resolution: "tmp@npm:0.2.7"
+  checksum: 10c0/59eb55584f2f07210d3231b6a1f6b5c2b9794d8a7b509c8ee867ed2acad6d2245ee2448b7937b676ffbff3155a70077edde8a69f9d7cf0f90c86a62e8910c357

Relevance

●●● Strong

Team often accepts updating workspace yarn.lock entries to fully align/dedupe versions after
dependency bumps.

PR-#2547
PR-#3407
PR-#3996

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The Lightspeed workspace lockfile now resolves tmp@^0.2.5 to 0.2.7, but other workspace lockfiles
still resolve the same range to 0.2.5, indicating the upgrade wasn’t applied consistently across
workspaces.

workspaces/lightspeed/yarn.lock[35173-35176]
workspaces/adoption-insights/yarn.lock[33568-33571]
workspaces/augment/yarn.lock[34121-34124]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
Only the Lightspeed workspace lockfile was updated to resolve `tmp@^0.2.5` to `0.2.7`, but other workspace `yarn.lock` files in this repo still pin `tmp@^0.2.5` at `0.2.5`. If your vulnerability/SBOM checks evaluate multiple workspaces (or the whole repo), the upgrade will be incomplete.

## Issue Context
Each workspace in this repo maintains its own `yarn.lock`, so dependency remediation often requires updating multiple lockfiles.

## Fix Focus Areas
- workspaces/lightspeed/yarn.lock[35173-35176]
- workspaces/adoption-insights/yarn.lock[33568-33571]
- workspaces/augment/yarn.lock[34121-34124]

## What to change
- Run the equivalent of your `yarn up -R tmp@^0.2.5` (or a repo-approved upgrade command) in each workspace that still locks `tmp` to `0.2.5`, and commit the resulting lockfile updates.
- Verify via grep (or your vulnerability tooling) that `tmp@npm:^0.2.5` no longer resolves to `0.2.5` in any workspace that is expected to be covered by the security fix.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

Context used

✅ Compliance rules (platform): 14 rules

✅ Cross-repo context

  Not relevant to this PR: redhat-developer/rhdh

  Not relevant to this PR: redhat-developer/rhdh-chart

  Not relevant to this PR: redhat-developer/rhdh-operator

  Not relevant to this PR: redhat-developer/rhdh-local

Tip of the day

💡 Did you know, you can reply 'qodo' on any finding to push back, ask questions, or dig deeper

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
⚠️ Please upload report for BASE (lightspeed/release-1.10@fce5805). Learn more about missing BASE report.
✅ All tests successful. No failed tests found.

Additional details and impacted files

@@                    Coverage Diff                     @@
##             lightspeed/release-1.10    #4241   +/-   ##
==========================================================
  Coverage                           ?   60.96%           
==========================================================
  Files                              ?     2098           
  Lines                              ?    65167           
  Branches                           ?    16942           
==========================================================
  Hits                               ?    39726           
  Misses                             ?    25219           
  Partials                           ?      222           

Flag	Coverage Δ		*Carryforward flag
adoption-insights	83.58% <ø> (?)		Carriedforward from 230b90c
ai-integrations	70.03% <ø> (?)		Carriedforward from 230b90c
app-defaults	69.60% <ø> (?)		Carriedforward from 230b90c
augment	69.36% <ø> (?)		Carriedforward from 230b90c
bulk-import	72.86% <ø> (?)		Carriedforward from 230b90c
cost-management	16.49% <ø> (?)		Carriedforward from 230b90c
dcm	32.85% <ø> (?)		Carriedforward from 230b90c
extensions	61.79% <ø> (?)		Carriedforward from 230b90c
global-floating-action-button	74.30% <ø> (?)		Carriedforward from 230b90c
global-header	61.68% <ø> (?)		Carriedforward from 230b90c
homepage	50.95% <ø> (?)		Carriedforward from 230b90c
konflux	91.01% <ø> (?)		Carriedforward from 230b90c
lightspeed	68.13% <ø> (?)
mcp-integrations	81.59% <ø> (?)		Carriedforward from 230b90c
orchestrator	36.36% <ø> (?)		Carriedforward from 230b90c
quickstart	62.88% <ø> (?)		Carriedforward from 230b90c
sandbox	79.56% <ø> (?)		Carriedforward from 230b90c
scorecard	83.58% <ø> (?)		Carriedforward from 230b90c
theme	64.54% <ø> (?)		Carriedforward from 230b90c
translations	8.49% <ø> (?)		Carriedforward from 230b90c
x2a	78.28% <ø> (?)		Carriedforward from 230b90c

*This pull request uses carry forward flags. Click here to find out more.

---

Continue to review full report in Codecov by Harness.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update fce5805...eb2d3e3. Read the comment docs.

🚀 New features to boost your workflow:

• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.