fix(ui): migrate remaining Monaco views to Shiki

[luvkapur]

Summary

• completes the read-only editor migration started in feat(lanes | component): redesign the changes & compare experience #10378 by moving the remaining code, API-reference, legacy compare, and aspect-compare views to the shared Shiki renderer
• imports the published API node-details and aspect-compare components so the workspace resolves the migrated source implementations
• removes the remaining explicit Monaco dependency from its owning component policy without workspace-level dependency exclusions
• preserves the existing routes and compatibility provider APIs

API Reference change request

https://bit.cloud/teambit/api-reference/~change-requests/migrate-api-code-rendering-v2

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

Code Review by Qodo

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

1. Workspace comparisons show wrong files 🐞 Bug ≡ Correctness

Description

CompareView builds the new sidebar file list from useCompareData() and useApiDiff() results,
but its enclosing CompareDataProvider and API query omit the page's host prop. When the page is
rendered for the workspace host, those queries fall back to the default host while
InlineComponentCompare uses the supplied workspace host, so the sidebar can list files or API
exports from a different comparison than the diff pane.

Code

scopes/component/component-compare/component-compare-page.tsx[R427-431]

+  const sidebarFiles = useMemo<FileInfo[] | undefined>(() => {
+    // The registry object is stable; its monotonic version invalidates this view-derived projection.
+    void fileRegistryVersion;
+    if (viewMode === 'code') return fileRegistry?.getFiles(componentId);
+    if (viewMode === 'config') return fileRegistry?.getAspectFiles(componentId);

Evidence

The page explicitly identifies workspace mode from its host prop and passes that host to
InlineComponentCompare, whereas the bulk provider and API hook calls omit it. The provider
documents that an omitted host uses the server default and must match the compared models; the API
hook likewise forwards only options.host to its query variable, proving the newly added sidebar
projection reads mismatched-host data.

scopes/component/component-compare/component-compare-page.tsx[88-94]
scopes/component/component-compare/component-compare-page.tsx[113-123]
scopes/component/component-compare/component-compare-page.tsx[227-264]
scopes/component/component-compare/component-compare-page.tsx[336-346]
scopes/component/component-compare/component-compare-page.tsx[427-444]
components/ui/component-compare/component-compare/compare-data-context.tsx[85-108]
components/ui/api-diff-view/use-api-diff.ts[67-84]

Agent prompt

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

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution
Issue description
The newly added sidebar derives its files from bulk comparison and API-diff queries that do not receive the `host` selected for `ComponentComparePage`. This makes workspace-host comparisons inconsistent with the inline diff renderer, which does receive that host.
Fix Focus Areas
- scopes/component/component-compare/component-compare-page.tsx[229-229]
- scopes/component/component-compare/component-compare-page.tsx[346-346]
Recommended Fix
Pass `host={hostFromProps}` to `CompareDataProvider`, and pass `host` in the options supplied to `useApiDiff(baseId, compareId, ...)`. Keep the existing `skip` option alongside the host so all data used by the sidebar and mode calculations targets the same host as `InlineComponentCompare`.

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

---

2. Fresh installs target a deleted package 🐞 Bug ☼ Reliability

Description

default-node-renderers is removed from .bitmap and its source directory, but pnpm-lock.yaml
still resolves the package to that deleted directory. APIReferenceUI still imports it while
workspace.jsonc requests released version ~0.0.39, so installs and builds based on the committed
lock cannot provide the renderer dependency.

Code

.bitmap[L1489-1492]

-    "renderers/default-node-renderers": {
-        "name": "renderers/default-node-renderers",
-        "scope": "teambit.api-reference",
-        "version": "0.0.38",

Evidence

The runtime import remains active, the workspace policy now selects the published package, but
multiple committed lockfile entries and the package snapshot still point to the deleted local
directory.

scopes/api-reference/api-reference/api-reference.ui.runtime.tsx[11-11]
workspace.jsonc[83-88]
pnpm-lock.yaml[6682-6684]
pnpm-lock.yaml[28716-28717]

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 local default-node-renderers component was removed, but the committed lockfile still resolves consumers to its deleted workspace directory instead of the released package declared in workspace policy.
## Fix Focus Areas
- .bitmap[1489-1495]
- workspace.jsonc[83-88]
- pnpm-lock.yaml[6682-6684]
- pnpm-lock.yaml[28716-28717]
## Recommended Fix
Regenerate the pnpm lockfile after removing the component so all default-node-renderers entries resolve the published `~0.0.39` package and no importer or package snapshot references `components/renderers/default-node-renderers`.

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

---

3. Turning off wrapping blanks large diffs ✓ Resolved 🐞 Bug ≡ Correctness

Description

DiffBody constrains wrapped content but attaches its scroll handler only while fixed-height
virtualization is active, so scrolling with wrapping enabled never updates scrollTop. For files
above the virtualization threshold, disabling wrapping retains the element's real scroll offset
while rendering rows near the stale state offset, leaving the viewport blank until another scroll
event occurs.

Code

components/ui/diff-viewer/diff-viewer.tsx[171]

+          constrainHeight={virtualize}

Evidence

Wrapping disables fixed-row virtualization while the newly added constraint keeps .body internally
scrollable. The only state update comes from an onScroll handler that is omitted when windowing
is false, while the compare screen enables wrapping by default and exposes a toggle that changes it
without remounting the viewer.

components/ui/diff-viewer/diff-viewer.tsx[168-172]
components/ui/diff-viewer/diff-viewer.tsx[293-326]
components/ui/diff-viewer/diff-viewer.tsx[337-345]
components/ui/diff-viewer/diff-viewer.module.scss[175-186]
components/ui/code-compare/code-compare-view/code-compare-view.tsx[62-65]
components/ui/code-compare/code-compare-view/code-compare-view.tsx[96-104]

Agent prompt

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

## Issue description
Wrapped, height-constrained diffs can be scrolled without updating the state later used by virtualization, causing a blank viewport when wrapping is disabled.
## Fix Focus Areas
- components/ui/diff-viewer/diff-viewer.tsx[293-338]
## Recommended Fix
Attach the scroll handler whenever the body is height-constrained, including while wrapping renders all rows, so `scrollTop` is current before virtualization activates. Add a regression test that scrolls a large wrapped diff and then disables wrapping.

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

---

View action required (4)

4. Windows diffs gain extra line breaks ✓ Resolved 🐞 Bug ≡ Correctness

Description

computeDiffLines and splitSourceLines split only on \n, leaving the \r from Windows line
endings in every item's rendered source text. The migrated comparison path sends repository blobs
directly through those items, so files stored with these endings render an additional segment break
inside each fixed-height diff row whenever plain-text fallback is used.

Code

components/ui/diff-viewer/diff-model.ts[73]

+  const lines = content.split('\n');

Evidence

Both the diff-part loop and the new source-preservation helper split exclusively on newline
characters. Their resulting strings are stored as text, oldText, and newText, then rendered
directly when highlighting is unavailable; the new code-comparison caller passes raw file contents
into this path.

components/ui/diff-viewer/diff-model.ts[40-63]
components/ui/diff-viewer/diff-model.ts[72-75]
components/ui/diff-viewer/diff-viewer.tsx[358-368]
components/ui/diff-viewer/diff-viewer.tsx[411-425]
components/ui/code-compare/code-compare-editor/code-compare-editor.tsx[54-68]

Agent prompt

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

## Issue description
Windows-style line endings leave a carriage-return character in each rendered diff line, producing extra segment breaks in fixed-height rows.
## Fix Focus Areas
- components/ui/diff-viewer/diff-model.ts[35-75]
- components/ui/diff-viewer/diff-model.spec.ts[15-39]
## Recommended Fix
Normalize line endings consistently for both diff comparison and side-specific source-line extraction, removing the trailing carriage return from each logical line without trimming other whitespace. Add tests covering changed and unchanged CRLF files in split and unified output.

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

---

5. The aspects route cannot resolve its modules 🐞 Bug ≡ Correctness

Description

ComponentCompareAspects imports the aspect context, query hook, and data model directly, but the
newly local aspect components have no dependency declarations for those packages. When these local
components are built or published without the former published aspect-comparison package supplying
them transitively, opening the legacy aspects route reaches unresolved runtime imports.

Code

components/ui/component-compare/compare-aspects/compare-aspects/compare-aspects.tsx[R12-14]

+import { ComponentCompareAspectsContext } from '@teambit/component.ui.component-compare.compare-aspects.context';
+import { useCompareAspectsQuery } from '@teambit/component.ui.component-compare.compare-aspects.hooks.use-compare-aspects';
+import { CompareAspectView } from '@teambit/component.ui.component-compare.compare-aspects.compare-aspect-view';

Evidence

The new route imports all three packages directly. The PR registers local components for the view
and route, while the workspace policy has no direct entries for these aspect-specific modules; the
lockfile shows they were previously supplied as dependencies of the removed published
compare-aspects package, so they cannot be relied on transitively by the newly local packages.

components/ui/component-compare/compare-aspects/compare-aspects/compare-aspects.tsx[12-14]
.bitmap[1799-1812]
workspace.jsonc[163-175]
pnpm-lock.yaml[58051-58061]

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 new local aspect-comparison components directly import the aspect context, query hook, and data-model packages, but do not declare them as their own dependencies. They are currently visible only through the formerly published `compare-aspects` package's transitive lockfile dependencies, which will not be included when these local components are resolved independently.
## Fix Focus Areas
- components/ui/component-compare/compare-aspects/compare-aspects/compare-aspects.tsx[12-14]
- .bitmap[1799-1812]
## Recommended Fix
Add direct dependency-resolver policy entries for `@teambit/component.ui.component-compare.compare-aspects.context`, `@teambit/component.ui.component-compare.compare-aspects.hooks.use-compare-aspects`, and `@teambit/component.ui.component-compare.compare-aspects.models.component-compare-aspects-model` to the new local aspect components as appropriate. Ensure the view component also declares its direct model dependency, then regenerate dependency metadata so the published packages include these imports.

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

---

6. Published editor cannot load its renderer 🐞 Bug ≡ Correctness

Description

CodeEditor imports helpers from @teambit/code.ui.diff-viewer, but the
components/ui/code-editor lockfile importer still declares the removed Monaco packages and has no
dependency on that new package. A consumer resolving the independently published code-editor
component therefore does not receive the package that supplies its new runtime imports.

Code

components/ui/code-editor/code-editor.tsx[R5-8]

+  normalizeLanguage,
+  resolveTokenColor,
+  useHighlightedLines,
+} from '@teambit/code.ui.diff-viewer';

Evidence

The new source import requires the shared renderer package, while the lockfile's importer for this
component lists Monaco and its other dependencies but no @teambit/code.ui.diff-viewer entry.

components/ui/code-editor/code-editor.tsx[3-8]
pnpm-lock.yaml[4321-4352]

Agent prompt

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

## Issue description
`components/ui/code-editor` now imports `@teambit/code.ui.diff-viewer`, but its component dependency metadata does not declare that package.
## Fix Focus Areas
- components/ui/code-editor/code-editor.tsx[3-8]
- pnpm-lock.yaml[4321-4352]
## Recommended Fix
Add `@teambit/code.ui.diff-viewer` as a runtime dependency of `ui/code-editor` using the repository's component dependency-management workflow, then regenerate the lockfile/component metadata. Remove the now-unused Monaco dependencies from this component if they have no remaining imports.

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

---

7. Published comparisons cannot load the diff 🐞 Bug ≡ Correctness

Description

CodeCompareEditor now renders DiffViewer from @teambit/code.ui.diff-viewer, but the
components/ui/code-compare importer has no dependency on that package. The component's generated
package metadata will therefore omit the renderer needed by code-comparison screens after this
migration.

Code

components/ui/code-compare/code-compare-editor/code-compare-editor.tsx[2]

+import { DiffViewer } from '@teambit/code.ui.diff-viewer';

Evidence

The changed editor imports DiffViewer, but the lockfile importer for components/ui/code-compare
contains no corresponding @teambit/code.ui.diff-viewer dependency entry.

components/ui/code-compare/code-compare-editor/code-compare-editor.tsx[1-2]
pnpm-lock.yaml[4201-4303]

Agent prompt

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

## Issue description
`components/ui/code-compare` now imports `@teambit/code.ui.diff-viewer`, but its component dependency metadata does not declare that package.
## Fix Focus Areas
- components/ui/code-compare/code-compare-editor/code-compare-editor.tsx[1-2]
- pnpm-lock.yaml[4201-4303]
## Recommended Fix
Add `@teambit/code.ui.diff-viewer` as a runtime dependency of `ui/code-compare` using the repository's component dependency-management workflow, then regenerate the lockfile/component metadata. Remove the now-unused Monaco dependencies from this component when no remaining source imports require them.

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

---

8. Early config clicks miss their aspect 🐞 Bug ≡ Correctness

Description

sidebarFiles reads the bulk registry’s aspect fieldName placeholders, while
InlineConfigCompare later replaces those entries with canonical aspect IDs used by the rendered
anchors. If a user selects a placeholder before the lazy config query finishes,
scrollToCompareSelection keeps observing for the original selector even after the sidebar entries
change, so that selection never scrolls to the aspect section.

Code

scopes/component/component-compare/component-compare-page.tsx[R430-431]

+    if (viewMode === 'code') return fileRegistry?.getFiles(componentId);
+    if (viewMode === 'config') return fileRegistry?.getAspectFiles(componentId);

Evidence

The bulk registry stores GraphQL aspect fieldName values, and the compare page immediately
projects those entries into the configuration sidebar. The mounted configuration view later
overwrites the same registry with canonical aspectId values and renders anchors from those IDs,
while the scroll helper retains only the selector captured at click time.

components/ui/component-compare/component-compare/component-compare.tsx[1022-1029]
components/ui/component-compare/component-compare/file-registry.tsx[42-50]
components/ui/inline-config-compare/inline-config-compare.tsx[128-139]
components/ui/inline-config-compare/inline-config-compare.tsx[153-160]
scopes/component/component-compare/component-compare-page.tsx[558-589]

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 configuration sidebar initially exposes bulk `fieldName` placeholders, but the mounted configuration view replaces them with canonical aspect IDs. A click made during that transition leaves the pending scroll operation searching for an identifier that will never be rendered.
## Fix Focus Areas
- scopes/component/component-compare/component-compare-page.tsx[425-444]
- scopes/component/component-compare/component-compare-page.tsx[518-525]
- components/ui/inline-config-compare/inline-config-compare.tsx[128-139]
- components/ui/component-compare/component-compare/file-registry.tsx[42-50]
## Recommended Fix
Avoid exposing noncanonical bulk aspect names as selectable targets, or reconcile the active selection when canonical aspect IDs replace the placeholders. Ensure any pending scroll is restarted with the updated canonical identifier rather than continuing to observe for the obsolete selector.

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

---

9. Added and removed aspects look modified ✓ Resolved 🐞 Bug ≡ Correctness

Description

sidebarAspects assigns MODIFIED to every aspectDiff, even though its producing loop has both
optional side values. When an aspect exists on only one side, the sidebar renders an M badge instead
of the supported N or D status, masking the add or delete classification used elsewhere.

Code

components/ui/inline-config-compare/inline-config-compare.tsx[132]

+      status: 'MODIFIED',

Evidence

The diff-building loop explicitly obtains optional base and comparison aspects, while the sibling
aspect status helper classifies their absence as new or deleted and the sidebar already renders
distinct N, D, and M labels.

components/ui/inline-config-compare/inline-config-compare.tsx[95-102]
components/ui/inline-config-compare/inline-config-compare.tsx[128-133]
components/ui/component-compare/compare-aspects/compare-aspects/compare-aspects.widgets.tsx[31-42]
components/ui/component-compare/component-compare/compare-sidebar.tsx[194-199]

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 new config sidebar labels every changed aspect as modified, including aspects that exist only in the base or comparison side.
## Fix Focus Areas
- components/ui/inline-config-compare/inline-config-compare.tsx[95-121]
- components/ui/inline-config-compare/inline-config-compare.tsx[128-134]
- components/ui/component-compare/compare-aspects/compare-aspects/compare-aspects.widgets.tsx[31-43]
## Recommended Fix
Store a status on each `AspectDiff` while both side values are available: `DELETED` when only the base aspect exists, `NEW` when only the comparison aspect exists, and `MODIFIED` otherwise. Pass that derived status into `sidebarAspects`.

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

---

10. Mobile comparisons lose the diff pane ✓ Resolved 🐞 Bug ≡ Correctness

Description

CompareView now mounts CompareSidebar for every mode except dependencies, while the sidebar CSS
fixes it at 280 pixels and disables shrinking. The surrounding .layout hides overflow and permits
.diffPane to shrink to zero, so narrow compare views have no usable width for code, config, tests,
previews, docs, or API output.

Code

scopes/component/component-compare/component-compare-page.tsx[R499-502]

+        <div className={styles.layout}>
+          {viewMode !== 'dependencies' && (
+            <CompareSidebar
+              groups={sidebarGroups}

Evidence

The new layout always includes the sidebar outside dependency mode; its fixed non-shrinking width
combines with a hidden-overflow parent and a shrinkable diff pane, and no responsive override exists
in the sidebar stylesheet.

scopes/component/component-compare/component-compare-page.tsx[499-515]
scopes/component/component-compare/component-compare-page.module.scss[24-30]
scopes/component/component-compare/component-compare-page.module.scss[86-92]
components/ui/component-compare/component-compare/compare-sidebar.module.scss[9-18]

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 newly embedded fixed-width sidebar consumes nearly all available width on mobile and narrow component-compare containers, while the diff pane is allowed to collapse.
## Fix Focus Areas
- scopes/component/component-compare/component-compare-page.tsx[499-517]
- scopes/component/component-compare/component-compare-page.module.scss[24-30]
- scopes/component/component-compare/component-compare-page.module.scss[86-92]
- components/ui/component-compare/component-compare/compare-sidebar.module.scss[9-18]
## Recommended Fix
Add responsive sidebar behavior for narrow containers, such as a collapsed drawer or overlay controlled by a toggle, while preserving a usable minimum width for the diff pane. Do not keep the fixed 280-pixel sidebar inline when the available width cannot accommodate both panes.

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

---

View review recommended (3)

11. Scoped config selections do not scroll ✓ Resolved 🐞 Bug ≡ Correctness

Description

sidebarFiles uses the full aspect names returned by getAspectFiles(), while
InlineConfigCompare builds each target anchor from only the aspect name's final path segment.
Selecting a scoped aspect such as teambit.react/react therefore searches for a nonexistent
full-name anchor and leaves the diff pane at its current position.

Code

scopes/component/component-compare/component-compare-page.tsx[430]

+    if (viewMode === 'config') return fileRegistry?.getAspectFiles(componentId);

Evidence

The registry stores bulk aspect fieldName values unchanged and the new sidebar consumes those
values directly. The rendered configuration comparison instead shortens every aspect ID with
split('/').pop(), while the new scroll helper searches using the sidebar's unshortened filename,
proving the selector mismatch for scoped aspects.

components/ui/component-compare/component-compare/component-compare.tsx[1022-1029]
components/ui/inline-config-compare/inline-config-compare.tsx[142-147]
scopes/component/component-compare/component-compare-page.tsx[543-554]

Agent prompt

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

## Issue description
Configuration sidebar entries retain full scoped aspect names, but rendered configuration anchors use shortened names, so selecting a scoped entry cannot locate or scroll to its diff.
## Fix Focus Areas
- scopes/component/component-compare/component-compare-page.tsx[424-443]
- components/ui/inline-config-compare/inline-config-compare.tsx[142-147]
## Recommended Fix
Use one canonical aspect identifier for both sidebar entries and `data-file-id` anchors. Prefer preserving the full aspect ID in the rendered anchor so similarly named aspects from different scopes remain distinct.

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

---

12. Controlled aspect clicks still navigate ✓ Resolved 🐞 Bug ≡ Correctness

Description

useHref returns the custom hook-generated URL in controlled mode whenever
hook.useUpdatedUrlFromQuery exists, instead of using controlledHref. Lane comparisons mark
aspect selection as controlled, so clicking their aspect tree can perform link navigation in
addition to the parent-provided selection callback.

Code

components/ui/component-compare/compare-aspects/compare-aspects/compare-aspects.tsx[42]

+    return state?.controlled && !hook?.useUpdatedUrlFromQuery ? controlledHref : href;

Evidence

Lane compare explicitly sets the aspects state to controlled, and the established code comparison
always resolves controlled selections to controlledHref even when a custom URL hook exists. The
new aspect implementation adds an extra condition that bypasses this behavior, then supplies the
resulting URL directly to the clickable tree while also passing the parent's click handler.

components/ui/compare/lane-compare/lane-compare.provider.tsx[90-101]
components/ui/code-compare/code-compare.tsx[84-98]
components/ui/component-compare/compare-aspects/compare-aspects/compare-aspects.tsx[72-80]

Agent prompt

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

## Issue description
Controlled aspect comparisons use a custom generated URL when a URL hook is present, bypassing the route-preserving href expected for parent-controlled selection.
## Fix Focus Areas
- components/ui/component-compare/compare-aspects/compare-aspects/compare-aspects.tsx[31-43]
## Recommended Fix
Return `controlledHref` whenever `state.controlled` is true, regardless of whether a custom URL hook exists. Use the custom or default generated aspect URL only for uncontrolled comparisons, matching the established code-comparison behavior.

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

---

13. Sidebar selections can miss their target ✓ Resolved 🐞 Bug ≡ Correctness

Description

onSelect schedules one scroll attempt, and scrollToCompareSelection returns permanently when its
single animation-frame query cannot find the target element. Deferred compare sections and lazy tabs
mount their data-file-id anchors asynchronously, so a selection made before that mount completes
remains selected in the sidebar without bringing the corresponding code, test, preview, config, or
API content into view.

Code

scopes/component/component-compare/component-compare-page.tsx[R549-551]

+  requestAnimationFrame(() => {
+    const element = pane.querySelector(selector);
+    if (!element) return;

Evidence

The new selection handler invokes the helper only once, while the helper has no retry path if the
queried anchor is absent. The target anchors are inside InlineComponentCompare, whose contents and
lazy tabs are explicitly mounted asynchronously via IntersectionObserver and a queued mount, so
the one-shot lookup can precede anchor creation.

scopes/component/component-compare/component-compare-page.tsx[507-512]
scopes/component/component-compare/component-compare-page.tsx[543-555]
components/ui/component-compare/component-compare/component-compare.tsx[639-659]
components/ui/component-compare/component-compare/component-compare.tsx[687-705]
components/ui/component-compare/component-compare/component-compare.tsx[730-760]

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 sidebar scroll helper makes a single `requestAnimationFrame` lookup and abandons the scroll when a deferred compare panel has not yet rendered its target anchor. Make selection scrolling occur after the target is available, including after lazy-tab and deferred-section mounting.
## Fix Focus Areas
- scopes/component/component-compare/component-compare-page.tsx[507-512]
- scopes/component/component-compare/component-compare-page.tsx[543-555]
## Recommended Fix
Store the pending component/file selection and perform scrolling from an effect that retries after rendering until the corresponding anchor exists, then clear the pending selection. Alternatively, have deferred panels notify the page after mounting and retry the lookup then; retain cleanup for queued frames or timers.

ⓘ 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 reply 'qodo' on any finding to push back, ask questions, or dig deeper

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗

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

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

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

Code review by qodo was updated up to the latest commit 8e13b62

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

Code review by qodo was updated up to the latest commit 25668ea

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

Code review by qodo was updated up to the latest commit 808b1e2

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

Code review by qodo was updated up to the latest commit 8519fa6

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

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

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

Code review by qodo was updated up to the latest commit 9532a5f

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

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

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

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

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

Code review by qodo was updated up to the latest commit 92f31e9

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

Code review by qodo was updated up to the latest commit 7e8884e

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

Code review by qodo was updated up to the latest commit 9546b02

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

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

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

Code review by qodo was updated up to the latest commit 6f4ef21

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

Code review by qodo was updated up to the latest commit 71a5d9d

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

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

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

Code Review by Qodo

New Review Started

This review has been superseded by a new analysis

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

1. Workspace comparisons show wrong files 🐞 Bug ≡ Correctness

CompareView builds the new sidebar file list from useCompareData() and useApiDiff() results,
but its enclosing CompareDataProvider and API query omit the page's host prop. When the page is
rendered for the workspace host, those queries fall back to the default host while
InlineComponentCompare uses the supplied workspace host, so the sidebar can list files or API
exports from a different comparison than the diff pane.

Agent Prompt

Issue description
The newly added sidebar derives its files from bulk comparison and API-diff queries that do not receive the `host` selected for `ComponentComparePage`. This makes workspace-host comparisons inconsistent with the inline diff renderer, which does receive that host.

Fix Focus Areas
- scopes/component/component-compare/component-compare-page.tsx[229-229]
- scopes/component/component-compare/component-compare-page.tsx[346-346]

Recommended Fix
Pass `host={hostFromProps}` to `CompareDataProvider`, and pass `host` in the options supplied to `useApiDiff(baseId, compareId, ...)`. Keep the existing `skip` option alongside the host so all data used by the sidebar and mode calculations targets the same host as `InlineComponentCompare`.

ⓘ 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 4c67e39