chore: update lockfile

[zkochan]

Proposed Changes

[qodo-free-for-open-source-projects]

Code Review by Qodo

🐞 Bugs (1) 📘 Rule violations (0) 📜 Skill insights (0)

1. Webpack template unregistered 🐞 Bug ≡ Correctness

Description

scopes/react/react/react.templates.ts removes ReactWebpackTemplate from the templates returned
by getTemplates(), so the Generator aspect will no longer expose that template for component
generation under this env.

Code

scopes/react/react/react.templates.ts[L20-21]

-  ReactWebpackTemplate.from({ env: 'bitdev.react/react-env' }),
-  // ReactWebpackAppTemplate.from({ env: 'bitdev.react/react-env' }),

Evidence

The current getTemplates() implementation builds templates from TemplateList.from([...]) and no
longer includes the webpack template in that list. That list is what ReactMain registers into the
Generator aspect, so removing an entry removes the template from generator-exposed templates.

scopes/react/react/react.templates.ts[13-26]
scopes/react/react/react.main.runtime.ts[470-478]

Agent prompt

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

### Issue description
The React env no longer registers the webpack-based generator template (`ReactWebpackTemplate`). This removes it from the template set exposed via `generator.registerComponentTemplate(...)`, which can break template selection/generation flows that expect it to exist.

### Issue Context
`getTemplates()` defines the full list of component templates, and `ReactMain` registers that list with the Generator aspect.

### Fix Focus Areas
- scopes/react/react/react.templates.ts[1-21]
- scopes/react/react/react.main.runtime.ts[470-478]

### Expected fix
- If webpack-based generation is still supported: re-add `ReactWebpackTemplate` import and its `.from(...)` entry in the `TemplateList.from([...])` list.
- If it is intentionally deprecated: add an explicit replacement path (e.g., documented Vite template), and update the PR description/changelog so consumers understand the removal and can migrate.

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

---

Tip of the day

💡 Did you know, you can describe a rule in plain language on the Rules page and Qodo drafts it for you

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗

Previous review results

Review updated until commit cfea426 ⚖️ Balanced

Results up to commit 99eee49

🐞 Bugs (0) 📘 Rule violations (0) 📎 Requirement gaps (0)

Great, no issues found!

Qodo reviewed your code and found no material issues that require review

[qodo-free-for-open-source-projects]

PR Summary by Qodo

Update pnpm lockfile

⚙️ Configuration changes 🕐 10-20 Minutes

AI Description

• Regenerate pnpm lockfile to refresh resolved dependency graph and metadata.
• Ensure installs remain reproducible with the current workspace overrides/resolution.

High-Level Assessment

The following are alternative approaches to this PR:

1. Pin pnpm version via packageManager field

• ➕ Reduces lockfile churn caused by pnpm version differences across machines/CI
• ➕ Improves reproducibility and review stability
• ➖ Requires aligning developer environments and CI to the pinned pnpm version
• ➖ May require tooling changes (corepack enable / CI setup adjustments)

2. Lockfile-only refresh (avoid dep upgrades)

• ➕ Minimizes risk of accidental dependency bumps
• ➕ Keeps PR strictly about normalization/re-resolution
• ➖ May not capture intended dependency upgrades if those were desired
• ➖ Still produces churn if the underlying resolver behavior changed

Recommendation: The lockfile update approach is fine, but reviewers should confirm whether changes are purely re-resolution vs. actual version movement. If lockfile-only PRs are frequently noisy, consider pinning the pnpm version (e.g., via a packageManager field + corepack) to stabilize future diffs.

Files changed (1) +21352 / -28965

Other (1) +21352 / -28965

pnpm-lock.yamlRegenerate pnpm dependency lockfile +21352/-28965

Regenerate pnpm dependency lockfile

• Updates the workspace dependency resolution snapshot captured by pnpm, including resolved versions, transitive graph entries, and associated lock metadata (e.g., integrity/resolution details). This is intended to keep installs consistent and reproducible for CI and developers.

pnpm-lock.yaml

[qodo-free-for-open-source-projects]

1. Webpack template unregistered 🐞 Bug ≡ Correctness

scopes/react/react/react.templates.ts removes ReactWebpackTemplate from the templates returned
by getTemplates(), so the Generator aspect will no longer expose that template for component
generation under this env.

Agent Prompt

### Issue description
The React env no longer registers the webpack-based generator template (`ReactWebpackTemplate`). This removes it from the template set exposed via `generator.registerComponentTemplate(...)`, which can break template selection/generation flows that expect it to exist.

### Issue Context
`getTemplates()` defines the full list of component templates, and `ReactMain` registers that list with the Generator aspect.

### Fix Focus Areas
- scopes/react/react/react.templates.ts[1-21]
- scopes/react/react/react.main.runtime.ts[470-478]

### Expected fix
- If webpack-based generation is still supported: re-add `ReactWebpackTemplate` import and its `.from(...)` entry in the `TemplateList.from([...])` list.
- If it is intentionally deprecated: add an explicit replacement path (e.g., documented Vite template), and update the PR description/changelog so consumers understand the removal and can migrate.

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

[qodo-free-for-open-source-projects]

Code review by qodo was updated up to the latest commit cfea426