chore: sync highlighter-provider to 0.0.234 and bump component-highlighter to 0.2.10

[davidfirst]

Version 0.0.234 of teambit.react/ui/highlighter-provider was released from another workspace. This change sets the .bitmap to this version, so the next tag does not make a conflict. The source files did not change.

It also updates @teambit/react.ui.component-highlighter to 0.2.10.

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

PR Summary by Qodo

Sync highlighter-provider version and bump component-highlighter

⚙️ Configuration changes 🕐 10-20 Minutes

AI Description

• Sync highlighter-provider’s bitmap version with the release to avoid a conflict on the next tag.
• Bump component-highlighter to 0.2.10 and refresh its lockfile resolutions.

Diagram

graph TD
  Bitmap["Component bitmap"] --> Provider["Highlighter provider"] --> Highlighter["Component highlighter"]
  Workspace["Workspace config"] --> Lock["pnpm lockfile"] --> Highlighter

Loading

High-Level Assessment

Synchronizing the bitmap directly and updating the workspace pin with its lockfile is appropriate; changing provider source or introducing another version-management path would not address the release conflict. Verify the lockfile’s changed React peer resolutions during review.

Files changed (3) +27 / -27

Other (3) +27 / -27

.bitmapRecord the released highlighter-provider version +1/-1

Record the released highlighter-provider version

• Changes the provider component’s tracked version from 0.0.233 to 0.0.234 so the next tag does not conflict with the release from another workspace.

.bitmap

workspace.jsoncPin component-highlighter to 0.2.10 +1/-1

Pin component-highlighter to 0.2.10

• Updates the workspace dependency from 0.2.9 to 0.2.10.

workspace.jsonc

pnpm-lock.yamlRefresh component-highlighter lockfile entries +25/-25

Refresh component-highlighter lockfile entries

• Updates importer entries, package integrity, and provider snapshots for component-highlighter 0.2.10. The regenerated lockfile also changes some peer-resolution entries and replaces pnpmfileChecksum metadata with untrackedPnpmfileReadPackageHook.

pnpm-lock.yaml

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

Code Review by Qodo

🐞 Bugs (1) 📘 Rule violations (0) 📎 Requirement gaps (0) 🎨 UX issues (0) 🔗 Cross-repo conflicts (0) 📜 Skill insights (0)

1. Installs re-resolve the workspace 🐞 Bug ➹ Performance

Description

The lockfile replaces pnpmfileChecksum with untrackedPnpmfileReadPackageHook: true, so pnpm
cannot cache the repository’s package hooks as part of the lockfile state. Every install that
changes dependencies can therefore resolve the dependency graph again, increasing install time and
potentially producing avoidable lockfile churn.

Code

pnpm-lock.yaml[35]

+untrackedPnpmfileReadPackageHook: true

Evidence

The repository’s dependency-resolver e2e test explicitly requires a nonempty pnpmfileChecksum and
rejects untrackedPnpmfileReadPackageHook. Its comment states that omitting the checksum makes pnpm
resolve every dependency again whenever anything changes, directly matching the lockfile
modification.

pnpm-lock.yaml[35-35]
e2e/harmony/dependency-resolver.e2e.ts[279-288]

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 lockfile changes `pnpmfileChecksum: bit-1` to `untrackedPnpmfileReadPackageHook: true`, causing pnpm to treat the repository’s read-package hooks as untracked and re-resolve dependencies on installs.
### Fix Focus Areas
- pnpm-lock.yaml[35-35]
### Recommended Fix
Regenerate the lockfile through Bit’s package-manager flow so it retains the generated `pnpmfileChecksum` and removes `untrackedPnpmfileReadPackageHook`, while preserving the intended `@teambit/react.ui.component-highlighter` 0.2.10 dependency update.

ⓘ 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 show, collapse, or hide each part of a finding: code, evidence, and all

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗

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

1. Installs re-resolve the workspace 🐞 Bug ➹ Performance

The lockfile replaces pnpmfileChecksum with untrackedPnpmfileReadPackageHook: true, so pnpm
cannot cache the repository’s package hooks as part of the lockfile state. Every install that
changes dependencies can therefore resolve the dependency graph again, increasing install time and
potentially producing avoidable lockfile churn.

Agent Prompt

### Issue description
The lockfile changes `pnpmfileChecksum: bit-1` to `untrackedPnpmfileReadPackageHook: true`, causing pnpm to treat the repository’s read-package hooks as untracked and re-resolve dependencies on installs.

### Fix Focus Areas
- pnpm-lock.yaml[35-35]

### Recommended Fix
Regenerate the lockfile through Bit’s package-manager flow so it retains the generated `pnpmfileChecksum` and removes `untrackedPnpmfileReadPackageHook`, while preserving the intended `@teambit/react.ui.component-highlighter` 0.2.10 dependency update.

ⓘ 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 fa4e836