Skip to content

Fix all patches for CC 2.1.2#352

Merged
bl-ue merged 3 commits intomainfrom
fix-patching-for-2.1.1
Jan 9, 2026
Merged

Fix all patches for CC 2.1.2#352
bl-ue merged 3 commits intomainfrom
fix-patching-for-2.1.1

Conversation

@basekevin
Copy link
Member

@basekevin basekevin commented Jan 9, 2026

Summary by CodeRabbit

  • Refactors
    • Broadened format support across context limits, message display, thinking visibility, verb handling, and line-number parsing for greater compatibility.
  • New Features
    • Added detection and handling for newer nested/array formats so displays and behaviors adapt to multiple versions.
  • Bug Fixes
    • Improved module loader detection for additional bundle types, reducing patch failures on varied builds.

✏️ Tip: You can customize this high-level summary in your review settings.

@coderabbitai
Copy link
Contributor

coderabbitai bot commented Jan 9, 2026

📝 Walkthrough

Walkthrough

Adds dual-format detection and branching for legacy and new formats across several patches (contextLimit, thinkerVerbs, thinkingVisibility, userMessageDisplay); enhances regex for escaped vs literal arrow in suppressLineNumbers; extends loader detection in index; expands toolsets component prop recognition and lookahead.

Changes

Cohort / File(s) Summary
Format Detection & Dual-Pattern Support
src/patches/contextLimit.ts, src/patches/thinkerVerbs.ts, src/patches/thinkingVisibility.ts, src/patches/userMessageDisplay.ts
Added parallel pattern matching for legacy and new formats, returning format-marked identifiers ('new_format'/'old_format') and branching patch generation accordingly; some flows now skip legacy-specific rewrites when new format detected.
Pattern & Regex Enhancements
src/patches/suppressLineNumbers.ts
Regex updated to match both literal arrow (→) and escaped \u2192 representations in line-number formatter patterns; comments adjusted.
Module Loader Detection
src/patches/index.ts
Added native loader detection (nativeLoaderPattern) with early return on native match; falls back to existing NPM-style detection and only logs when neither matches.
Component Props / Lookahead Expansion
src/patches/toolsets.ts
Main app component regex extended to include mainThreadAgentDefinition and disableSlashCommands; increased useState extraction lookahead from 20 to 500 chars for 2.1.x compatibility.
Manifest / Packaging
package.json
Minor manifest adjustments indicated by diff metadata.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~25 minutes

Possibly related PRs

Suggested reviewers

  • bl-ue

Poem

🐰 Hoppy patches for formats old and new,
Dual detection makes our code hop through!
Arrows both literal and escaped in sight,
Loaders found early, props widened right.
A little rabbit cheers: patching done—delight! ✨

🚥 Pre-merge checks | ✅ 3
✅ Passed checks (3 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check ✅ Passed The title 'Fix all patches for CC 2.1.2' accurately reflects the core objective of the PR, which involves updating multiple patch files to support the new 2.1.2 release format.
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

✏️ Tip: You can configure your own custom pre-merge checks in the settings.

✨ Finishing touches
  • 📝 Generate docstrings

📜 Recent review details

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between e5a6af9 and b2114cc.

📒 Files selected for processing (1)
  • src/patches/userMessageDisplay.ts
🔇 Additional comments (3)
src/patches/userMessageDisplay.ts (3)

12-29: LGTM! Pattern correctly detects three-level nested structure.

The regex pattern accurately captures the new format with the pointer icon element. The identifiers extraction correctly stores the React variable, text component, message variable, and format marker.


31-47: LGTM! Old format detection is correct.

The pattern correctly identifies the legacy single-component format with the hardcoded "> " prefix.


49-53: LGTM! Proper error handling.


Comment @coderabbitai help to get the list of available commands and usage tips.

Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)
src/patches/userMessageDisplay.ts (1)

193-217: New and old format branches generate identical content.

The conditional on isNewFormat (lines 193-217) produces the exact same newContent for both branches. The comment on line 194 states "preserve the pointer icon structure," but the generated content doesn't include the pointer at all.

This appears to be incomplete implementation. The new format should likely include the pointer using the captured icons object:

🐛 Potential fix to preserve pointer for new format
  if (isNewFormat) {
    // New format: preserve the pointer icon structure but apply customizations
+   const iconsObject = location.identifiers![4];
    newContent = `
return ${reactVar}.createElement(
  ${boxComponent},
  ${boxAttrsObjStr},
+  ${reactVar}.createElement(
+    ${textComponent},
+    {color:"subtle"},
+    ${iconsObject}.pointer," "
+  ),
  ${reactVar}.createElement(
    ${textComponent},
    ${textAttrsObjStr},
    ${needsChalk ? chalkChain + '(' : ''}${formattedMessage}${needsChalk ? ')' : ''}
  )
);`;
  } else {

Alternatively, if both formats intentionally produce the same output, remove the dead conditional and the unused icons capture.

🤖 Fix all issues with AI agents
In @src/patches/userMessageDisplay.ts:
- Around line 22-28: The identifiers array records an icons object at
newMessageDisplayMatch[4] but writeUserMessageDisplay only destructures four
elements and never uses that icons object, so either remove it from the
identifiers array or use it; to fix, either (A) remove newMessageDisplayMatch[4]
from the identifiers array to avoid unused data, or (B) preserve and propagate
it by updating writeUserMessageDisplay to destructure a fifth element (the icons
object) and inject it into the generated content where the "preserve the pointer
icon structure" comment references the icons/pointer object so the pointer icon
structure is actually preserved; update the identifiers array and the
destructuring in writeUserMessageDisplay accordingly.
🧹 Nitpick comments (1)
src/patches/userMessageDisplay.ts (1)

41-46: Consider adding explicit format marker for consistency.

Unlike thinkerVerbs.ts which adds 'old_format' to the identifiers array for the old format, this file relies on formatType being undefined. While this works, adding an explicit marker would be more consistent across patch files.

🔧 Suggested change for consistency
       identifiers: [
         oldMessageDisplayMatch[1],
         oldMessageDisplayMatch[2],
         oldMessageDisplayMatch[3],
+        'old_format',
       ],
📜 Review details

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 9b1b874 and e5a6af9.

📒 Files selected for processing (7)
  • src/patches/contextLimit.ts
  • src/patches/index.ts
  • src/patches/suppressLineNumbers.ts
  • src/patches/thinkerVerbs.ts
  • src/patches/thinkingVisibility.ts
  • src/patches/toolsets.ts
  • src/patches/userMessageDisplay.ts
🧰 Additional context used
🧬 Code graph analysis (1)
src/patches/thinkerVerbs.ts (1)
src/patches/index.ts (1)
  • showDiff (88-126)
🔇 Additional comments (8)
src/patches/suppressLineNumbers.ts (1)

19-34: LGTM! Robust Unicode arrow handling.

The regex enhancement correctly uses non-capturing groups to match both literal (→) and escaped Unicode (\u2192) arrow representations without affecting capture group numbering. The backreferences (\1, \2) remain accurate.

src/patches/toolsets.ts (2)

85-87: LGTM! Backward-compatible prop detection.

The updated regex correctly includes both legacy props (initialPrompt, initialCheckpoints) and new 2.1.x props (mainThreadAgentDefinition, disableSlashCommands), ensuring the pattern matches across multiple Claude Code versions.


131-132: Reasonable lookahead extension for 2.1.x compatibility.

The 25x increase (20 → 500 chars) accommodates additional code inserted between the function signature and useState in 2.1.x. The specific pattern (let[var,setter]=getter()) minimizes false-positive risk.

src/patches/index.ts (1)

158-184: LGTM! Clean dual-loader detection.

The native loader detection correctly uses the !=null check as a discriminator and appropriately sizes the search windows (2000 chars for native, 1000 for NPM). The early-return pattern avoids unnecessary work.

src/patches/contextLimit.ts (1)

5-31: LGTM! Dual-format detection with consistent insertion.

Both patterns correctly identify their respective formats and insert at the same relative position (after the opening brace). The backreference \4 in the new pattern is valid JavaScript regex. While these patterns are inherently brittle to minification changes, this is unavoidable in a patching system.

src/patches/thinkingVisibility.ts (1)

13-98: LGTM! Correct dual-format thinking visibility patching.

The implementation properly handles both new (braces-wrapped with hideInTranscript) and old (no braces) formats. The capture groups and replacement logic correctly reconstruct the case statements with isTranscriptMode: true while preserving other fields. The format marker at identifiers[3] cleanly discriminates between formats.

src/patches/thinkerVerbs.ts (2)

5-48: LGTM!

The dual-format detection logic is well-structured. The performance optimization with boundary characters at the start of patterns is a nice touch. The old_format marker approach cleanly signals which code path to take downstream.


70-129: LGTM!

The conditional patching logic is sound—new format uses the array directly while old format requires the additional function patch to access .words. The early return on line 128 cleanly handles the new format case.

@bl-ue bl-ue changed the title Fix all patches for CC 2.1.1 Fix all patches for CC 2.1.2 Jan 9, 2026
Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 0

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)
src/patches/userMessageDisplay.ts (1)

193-217: Critical: New format generation missing pointer icon and both branches are identical.

Two critical issues:

  1. Missing pointer icon in new format: The detection pattern at lines 15-16 correctly identifies a three-level nested structure with a pointer icon createElement (with color:"subtle"), but the generated code at lines 195-204 only produces a two-level structure. The middle layer containing the pointer icon is completely omitted.

  2. Identical code in both branches: Lines 195-204 (new format) and lines 207-216 (old format) generate exactly the same code. This defeats the purpose of having two separate format branches. If the formats are truly different (as indicated by the detection patterns), the generated code should reflect those differences.

The new format generation should include all three createElement calls to match the detected structure.

🐛 Suggested fix for new format generation

The new format should preserve the three-level structure with the pointer icon. However, I need to verify what variables are available for the pointer icon. Consider capturing the pointer icon variable in the detection pattern and using it in generation:

  const [reactVar, textComponent, messageVar, formatType] =
    location.identifiers!;
  const isNewFormat = formatType === 'new_format';

  // Replace {} in format string with the message variable
  const formattedMessage =
    '"' + format.replace(/\{\}/g, `"+${messageVar}+"`) + '"';

  let newContent: string;

  if (isNewFormat) {
-    // New format: preserve the pointer icon structure but apply customizations
+    // New format: preserve the three-level structure with pointer icon
    newContent = `
return ${reactVar}.createElement(
  ${boxComponent},
  ${boxAttrsObjStr},
+  ${reactVar}.createElement(
+    ${textComponent},
+    {color:"subtle"},
+    /* TODO: Add pointer icon variable here - needs to be captured in detection pattern */
+    " "
+  ),
  ${reactVar}.createElement(
    ${textComponent},
    ${textAttrsObjStr},
    ${needsChalk ? chalkChain + '(' : ''}${formattedMessage}${needsChalk ? ')' : ''}
  )
);`;
  } else {
    // Old format
    newContent = `
return ${reactVar}.createElement(
  ${boxComponent},
  ${boxAttrsObjStr},
  ${reactVar}.createElement(
    ${textComponent},
    ${textAttrsObjStr},
    ${needsChalk ? chalkChain + '(' : ''}${formattedMessage}${needsChalk ? ')' : ''}
  )
);`;
  }

Note: You'll also need to update the detection pattern to capture and return the pointer icon variable (group 4 from the regex at line 16), and adjust the identifiers array to include it.

📜 Review details

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between e5a6af9 and b2114cc.

📒 Files selected for processing (1)
  • src/patches/userMessageDisplay.ts
🔇 Additional comments (3)
src/patches/userMessageDisplay.ts (3)

12-29: LGTM! Pattern correctly detects three-level nested structure.

The regex pattern accurately captures the new format with the pointer icon element. The identifiers extraction correctly stores the React variable, text component, message variable, and format marker.


31-47: LGTM! Old format detection is correct.

The pattern correctly identifies the legacy single-component format with the hardcoded "> " prefix.


49-53: LGTM! Proper error handling.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants