Conversation
Fixed preview generation failing with "Claude Code process exited with code 1" error. Root cause: Preview generation was using ClaudeAgentSDKRepository (based on LLM_PROVIDER env var) which spawns Claude Code processes unnecessarily for simple preview generation tasks. Changes: - Force preview generation to always use OpenRouterRepository for simple, fast model calls - Add GENERATE_PREVIEW_MODEL env var to configure preview model (default: gpt-4o-mini) - Remove all debug console.log statements added during investigation - Update .env.production.example with new env var documentation 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
Remove MISTRAL_API_KEY, YOUTUBE_API_KEY, RESEND_API_KEY, and SENDGRID_API_KEY from environment validation. These variables are unused in the main application (Mistral/YouTube are only used in a non-functional sub-project, Resend/SendGrid were commented fallback code). Simplified email.ts to only reference Brevo. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
WalkthroughAdds GENERATE_PREVIEW_MODEL env var and wires it into preview generation using OpenRouter; removes several unused API key env declarations; consolidates email sending to Brevo-only; adds orphan-finder and cleanup scripts; implements atomic batch move/update for map items and related constants and DB write-query. Changes
Sequence Diagram(s)sequenceDiagram
actor Caller
participant Inngest as Inngest fn
participant Service as PreviewGeneratorService
participant Env as ServerEnv
participant OpenRouter as OpenRouterRepository
Caller->>Inngest: generatePreview(tile)
Inngest->>Service: generatePreview(tile)
Service->>Env: read GENERATE_PREVIEW_MODEL
Service->>OpenRouter: instantiate with OPENROUTER_API_KEY
OpenRouter-->>Service: model response (uses GENERATE_PREVIEW_MODEL)
Service-->>Inngest: preview result
Note right of OpenRouter: if not configured -> throw error (stack logged)
sequenceDiagram
actor API
participant Service as MapItemService
participant Repo as MapItemRepository
participant DB as DbWriteQueries
API->>Service: move(item, newCoords, newParent)
Service->>Repo: batchUpdateItemAndDescendants(params)
Repo->>DB: writeQueries.batchUpdateItemAndDescendants(params)
DB-->>Repo: updatedCount
Repo-->>Service: updatedCount
Service-->>API: success / updatedCount
Note right of DB: single atomic path rewrite for item + descendants
Estimated code review effort🎯 4 (Complex) | ⏱️ ~45 minutes
Possibly related PRs
Poem
Pre-merge checks and finishing touches❌ Failed checks (1 warning, 1 inconclusive)
✅ Passed checks (1 passed)
✨ Finishing touches
🧪 Generate unit tests (beta)
📜 Recent review detailsConfiguration used: CodeRabbit UI Review profile: CHILL Plan: Pro 📒 Files selected for processing (9)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (4)
🔇 Additional comments (9)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (6)
.env.production.example(1 hunks)src/env.js(2 hunks)src/lib/domains/agentic/infrastructure/inngest/functions.ts(2 hunks)src/lib/domains/agentic/repositories/openrouter.repository.ts(3 hunks)src/lib/domains/agentic/services/preview-generator.service.ts(2 hunks)src/server/email.ts(1 hunks)
🧰 Additional context used
🧬 Code graph analysis (2)
src/lib/domains/agentic/services/preview-generator.service.ts (1)
src/env.js (2)
env(7-89)env(7-89)
src/lib/domains/agentic/infrastructure/inngest/functions.ts (2)
src/lib/domains/agentic/repositories/openrouter.repository.ts (1)
OpenRouterRepository(49-357)src/env.js (2)
env(7-89)env(7-89)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (3)
- GitHub Check: Build
- GitHub Check: Tests - Phase 1 (Main Suite)
- GitHub Check: ESLint
🔇 Additional comments (8)
src/lib/domains/agentic/repositories/openrouter.repository.ts (1)
67-88: LGTM! Formatting improvements enhance readability.The whitespace additions around the request body construction, debug logging, and response parsing improve code clarity without changing behavior.
.env.production.example (1)
48-51: LGTM! Well-documented configuration addition.The new
GENERATE_PREVIEW_MODELvariable is clearly documented with sensible defaults and helpful guidance on model selection. The default "gpt-4o-mini" aligns with the schema definition insrc/env.js.src/lib/domains/agentic/infrastructure/inngest/functions.ts (1)
265-266: LGTM! Enhanced error logging.Adding the stack trace to error logging will significantly improve debugging capabilities when preview generation fails.
src/server/email.ts (1)
76-78: LGTM! Clearer error messaging.The updated error message explicitly states that
BREVO_API_KEYis required, which improves clarity for users configuring production email. This aligns well with the PR's goal of consolidating to a single email provider.src/env.js (2)
22-22: LGTM! Proper environment variable schema.The
GENERATE_PREVIEW_MODELvariable is correctly added with appropriate type validation and a sensible default of "gpt-4o-mini".
63-63: LGTM! Runtime environment mapping is correct.The runtime environment mapping for
GENERATE_PREVIEW_MODELis properly configured to read fromprocess.env.src/lib/domains/agentic/services/preview-generator.service.ts (2)
4-4: LGTM! Proper environment import.The
envimport is correctly added to support dynamic model selection.
52-52: LGTM! Configurable model selection.Replacing the hardcoded model with
env.GENERATE_PREVIEW_MODELprovides flexibility while maintaining backward compatibility through the default value. This aligns well with the PR's objective of making preview generation configurable.
### Deprecated Code Removal - Remove `batchUpdateDescendantPaths` function (deprecated) - Remove `batchUpdateChildrenParentIds` function (unused) - Simplify `_batchUpdateItemAndDescendants` to use atomic updates only - Remove legacy fallback code and sequential update methods - Clean up unused imports (`like` from drizzle-orm) ### Orphan Detection Tools - Add `pnpm db:find-orphans` script for detecting orphan map items - Add `pnpm db:cleanup-orphans` script with TypeScript/Drizzle implementation - Two cleanup modes: `--mode=delete` or `--mode=reparent` - Dry run support: `--dry-run` flag - Detailed reporting and verification - Remove old SQL-based cleanup script ### Type System Improvements - Add `batchUpdateItemAndDescendants` to MapItemRepository interface - Update test mocks to include new repository method - Remove unsafe type casting in movement helpers All changes maintain backward compatibility and pass typecheck + lint. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com>
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (11)
src/lib/domains/mapping/_actions/_map-item-movement-helpers.ts (1)
72-83: Batch move integration looks good; clean up legacy helperThe
movemethod’s switch to_batchUpdateItemAndDescendantsis a nice simplification and aligns with the new atomic DB operation. Keeping_getDescendantsin the signature but unused (with a leading underscore) preserves the public API while avoiding lint noise.The private
_updateItemCoordinatesmethod is now effectively dead (private and not referenced in this class). You can safely delete it to reduce noise and avoid future confusion about which move path is actually used.Also applies to: 180-196
src/lib/domains/mapping/infrastructure/map-item/db.ts (1)
345-356: Repository delegate for batch move matches write-queries contractThe new
batchUpdateItemAndDescendantsmethod cleanly delegates toWriteQueriesand matches the expected signature. From a behavior standpoint this looks correct.You might optionally tighten the typing by reusing the shared
Coordinterface foroldCoords/newCoordsinstead of repeating{ userId; groupId; path }, but that’s just a consistency improvement.src/lib/domains/mapping/services/_item-services/_item-management.service.ts (1)
167-259: Solid batch creation logic with proper depth ordering.The depth-based grouping and sequential processing maintains referential integrity while batching inserts efficiently.
One optional improvement: consider adding a defensive check at line 250 to verify
createdItems.length === createDataArray.lengthbefore iterating. While the repository contract should guarantee this, an explicit check would make the assumption visible and fail fast if violated.Optional defensive check:
); + + // Verify batch creation succeeded completely + if (createdItems.length !== createDataArray.length) { + throw new Error( + `Batch creation mismatch: expected ${createDataArray.length} items, got ${createdItems.length}` + ); + } // Store mappings for next level for (let i = 0; i < createDataArray.length; i++) {scripts/cleanup-orphan-items.ts (4)
49-116: De-duplicate orphan detection logic and consider batching queriesThis
findOrphanItemslargely duplicates the detection logic inscripts/find-orphan-items.ts, but uses the drizzlemapItemstable instead of thevde_map_itemsview. Over time, these can drift.It may be worth:
- Extracting a shared orphan-detection helper (parameterized by query backend) so both scripts stay in sync.
- Optionally batching lookups (e.g., pre-building a map of existing paths per user/group) to avoid two DB roundtrips per item when scanning large datasets.
125-135: UseinArrayfor cleaner, type-safe filtering byorphanIdsThe
ANYexpression viasql\${mapItems.id} = ANY(${orphanIds})`` works but is less idiomatic and can be brittle with array parameter typing.Drizzle provides
inArrayfor this case:-import { eq, and, sql } from "drizzle-orm"; +import { eq, and, sql, inArray } from "drizzle-orm"; @@ - .innerJoin(mapItems, eq(baseItems.id, mapItems.refItemId)) - .where(sql`${mapItems.id} = ANY(${orphanIds})`); + .innerJoin(mapItems, eq(baseItems.id, mapItems.refItemId)) + .where(inArray(mapItems.id, orphanIds));This should also make it easier to extend with additional predicates if needed.
137-185: Optional: batch delete/reparent operations for many orphansBoth
deleteOrphansandreparentOrphansissue one SQL statement per orphan. That’s fine for small maintenance runs, but if you ever clean up thousands of rows, it may be faster to use a singleIN/inArrayquery per mode.You can keep the per-item logging but still group IDs into a batched delete/update once logging is done.
219-285: Avoidprocess.exitso the client can shut down cleanlyInside
main, callingprocess.exit(1)in thecatchcan cut short theawait client.end()infinally, depending on Node’s shutdown timing.A safer pattern is:
- } catch (error) { - console.error("❌ Error:", error); - process.exit(1); - } finally { + } catch (error) { + console.error("❌ Error:", error); + process.exitCode = 1; + } finally { await client.end(); }This still returns a non-zero exit code but lets the DB client close gracefully.
scripts/find-orphan-items.ts (4)
1-10: Align usage docs with the newdb:find-orphansscriptNow that
package.jsonexposesdb:find-orphans(with dotenv wiring), consider updating the header to mention:
pnpm db:find-orphansas the primary entrypoint, and- optionally keep
pnpm tsx scripts/find-orphan-items.tsas an advanced/alt form.This keeps the docs in sync with how the tool is meant to be run.
36-104: Orphan detection works, but may be chatty for large datasetsThe detection logic looks correct for the “missing immediate parent path” definition, and the ancestry check is a nice extra signal. Just note that:
findOrphanItemsissues two queries per item (parent + root checks).checkAncestryToRootperforms an additional query per step up the path.That’s fine for moderate sizes and one-off maintenance, but if you expect very large
vde_map_items, you might eventually want to batch parent lookups or reuse the drizzle-based helper fromscripts/cleanup-orphan-items.tsto avoid N+1-style patterns.Also applies to: 106-141
174-189: Reference the new cleanup script alongside the raw SQLGiven you now have
scripts/cleanup-orphan-items.ts(exposed viapnpm db:cleanup-orphans), it may help to mention that script here as the preferred cleanup mechanism, with the example SQL kept as a low-level fallback.This keeps users on the same remediation path as your automated tooling.
193-198: Use exitCode instead ofprocess.exitfor graceful shutdownSimilar to the cleanup script, the
process.exit(1)incatchcan interfere with the asyncawait sql.end()infinally.You can keep the non-zero exit status and let the client close cleanly by doing:
- } catch (error) { - console.error("❌ Error:", error); - process.exit(1); - } finally { + } catch (error) { + console.error("❌ Error:", error); + process.exitCode = 1; + } finally { await sql.end(); }
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (11)
-
package.json(1 hunks) -
scripts/cleanup-orphan-items.ts(1 hunks) -
scripts/find-orphan-items.ts(1 hunks) -
src/lib/domains/agentic/infrastructure/inngest/functions.ts(2 hunks) -
src/lib/domains/mapping/_actions/__tests__/map-item-transactions.test.ts(1 hunks) -
src/lib/domains/mapping/_actions/_map-item-movement-helpers.ts(2 hunks) -
src/lib/domains/mapping/_repositories/map-item.ts(1 hunks) -
src/lib/domains/mapping/constants.ts(1 hunks) -
src/lib/domains/mapping/infrastructure/map-item/db.ts(1 hunks) -
src/lib/domains/mapping/infrastructure/map-item/queries/write-queries.ts(3 hunks) -
src/lib/domains/mapping/services/_item-services/_item-management.service.ts(4 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
- src/lib/domains/agentic/infrastructure/inngest/functions.ts
🧰 Additional context used
🧬 Code graph analysis (5)
src/lib/domains/mapping/services/_item-services/_item-management.service.ts (1)
src/lib/domains/mapping/constants.ts (2)
MAX_DESCENDANTS_FOR_OPERATION(35-35)MAX_HIERARCHY_DEPTH(22-22)
scripts/cleanup-orphan-items.ts (1)
src/server/db/index.ts (2)
schema(78-78)db(75-75)
src/lib/domains/mapping/_repositories/map-item.ts (1)
src/lib/domains/mapping/utils/hex-coordinates.ts (1)
Coord(22-29)
src/lib/domains/mapping/infrastructure/map-item/queries/write-queries.ts (3)
src/lib/domains/mapping/utils/hex-coordinates.ts (1)
Coord(22-29)src/lib/domains/mapping/infrastructure/map-item/mappers.ts (1)
pathToString(34-36)src/server/db/schema/_tables/mapping/map-items.ts (1)
mapItems(38-85)
src/lib/domains/mapping/_actions/_map-item-movement-helpers.ts (2)
src/lib/domains/mapping/_objects/map-item.ts (1)
MapItemWithId(133-133)src/lib/domains/mapping/utils/hex-coordinates.ts (1)
Coord(22-29)
🔇 Additional comments (10)
src/lib/domains/mapping/_actions/__tests__/map-item-transactions.test.ts (1)
19-44: Mock updated to cover new batch API is consistentAdding
batchUpdateItemAndDescendants: vi.fn()keeps the test repository aligned with theMapItemRepositoryinterface and ensures transaction-aware flows using the new batch operation won’t crash under test due to missing methods. No issues from a test behavior standpoint.src/lib/domains/mapping/constants.ts (1)
1-56: Well-documented operational limits for mapping operationsThe constants and accompanying comments are clear and give good context for why these values were chosen. From a code perspective this looks solid; just make sure
PERFORMANCE_ANALYSIS.mdstays in sync with future tuning so the rationale doesn’t drift over time.src/lib/domains/mapping/infrastructure/map-item/queries/write-queries.ts (1)
1-1: Remove redundant try/catch block; edge cases prevented by upstream validationThe
batchUpdateItemAndDescendantsmethod correctly handles path transformation, and the empty-path edge cases flagged in the review are actually prevented by upstream validation. Line 90-91 in_map-item-movement-helpers.tsexplicitly forbids moving center items (CANNOT_MOVE_CENTER_ITEM), so botholdCoords.pathandnewCoords.pathare guaranteed non-empty before reaching this query.That said, two improvements are warranted:
Remove the redundant try/catch (lines 145-147). The wrapper adds no value; the error propagates identically without it.
Raw SQL parameterization (lines 147-150) uses
sql.raw()to inject'${newPathString}'and'${oldPathString},%'. While injection risk is low (Direction enum is constrained to integers), parameterizing through drizzle is cleaner and more maintainable for future changes. This is a style improvement, not a bug.Likely an incorrect or invalid review comment.
src/lib/domains/mapping/_repositories/map-item.ts (1)
131-147: LGTM! Clean interface addition for atomic batch updates.The new method signature is well-documented and addresses the duplicate key conflict issue mentioned in the description. Consolidating the moved item and descendant updates into a single atomic operation is a solid improvement.
src/lib/domains/mapping/services/_item-services/_item-management.service.ts (4)
11-11: LGTM! Import additions support the new validation and batch logic.The new type imports and constants are properly utilized in the helper methods below.
Also applies to: 17-20
101-102: LGTM! Good defensive validation before expensive copy operations.Failing fast when hierarchy limits are exceeded prevents wasted resources and provides clear feedback.
123-129: LGTM! Batch creation strategy improves performance.Processing items by depth level allows efficient batch inserts while maintaining parent-child dependencies.
261-289: LGTM! Robust validation with clear error messages.The hierarchy limit checks protect against resource exhaustion, and the error messages provide helpful guidance. The relative depth calculation correctly handles the source item and its descendants.
package.json (1)
17-18: New orphan DB scripts are wired correctlyThe commands align with the new TS entrypoints and follow the existing dotenv pattern for DB scripts; no issues from my side.
scripts/cleanup-orphan-items.ts (1)
46-47: Current code is valid TypeScript—refactor suggestion is optional best practice, not criticalThe review's claim that
ReturnType<typeof drizzle<typeof schema>>is "not valid TypeScript" and "will fail type-checking" is contradicted by official drizzle documentation and community examples. Web search results confirm this pattern is valid and produces correctly typed results.The suggested refactor to use
PostgresJsDatabase<typeof schema>is indeed the official recommended pattern from drizzle docs and is cleaner, but it's an optional improvement, not a critical fix. The current implementation works correctly and does not fail type-checking.Likely an incorrect or invalid review comment.
| /** | ||
| * Cleanup orphan map items that don't have a valid ancestry path to a root item. | ||
| * | ||
| * This script provides options to: | ||
| * 1. Delete orphan items (and their base items if not referenced elsewhere) | ||
| * 2. Re-parent orphans to root (convert them to root items) | ||
| * | ||
| * Run with: | ||
| * pnpm db:cleanup-orphans | ||
| * pnpm db:cleanup-orphans --mode=delete | ||
| * pnpm db:cleanup-orphans --mode=reparent | ||
| * pnpm db:cleanup-orphans --dry-run | ||
| */ |
There was a problem hiding this comment.
Docstring over-promises base-item cleanup
The header says this script can “delete orphan items (and their base items if not referenced elsewhere)”, but the implementation only deletes/reparents entries in mapItems; base items are never inspected or removed.
Either:
- implement the base-item cleanup logic, or
- trim the comment so it only describes the current behavior.
### Test Failures Fixed - Resolved `ReferenceError: __vite_ssr_exportName__ is not defined` error - All 1082 tests now passing (1074 passed, 8 skipped, 0 failed) - Tests were failing because Vite 7 introduced breaking changes in SSR transformation ### Package Downgrades - Downgrade `vitest` from 3.0.7 to 2.1.9 (latest stable 2.x) - Downgrade `@vitest/browser`, `@vitest/coverage-v8`, `@vitest/ui` to 2.1.9 - Change Vite from pinned `6.3.5` to `^6.3.5` for patch updates - Add pnpm override `"vite@>=7.0.0": "6.3.5"` to block Vite 7 - Remove conflicting Vite overrides from vulnerability fix ### Import Path Improvements - Update `src/test-utils/event-bus.ts` to import from `~/lib/utils/event-bus/types` - Update `src/test-utils/__tests__/event-bus.test.ts` to use direct imports - Avoid barrel exports (`~/app/map`) to prevent circular dependencies - More explicit dependency graph and better maintainability ### Architecture Fix - Add `~/env` to allowed dependencies in agentic services - Fixes undeclared dependency violation in `preview-generator.service.ts` ### Root Cause The "fix vulnerabilities" commit (e9707d1) added pnpm overrides that inadvertently allowed Vitest 3.x to pull in Vite 7.x. Vite 7 has breaking changes in SSR transformation that are incompatible with the current setup. Staying on Vite 6.x until proper Vite 7 support is available. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
There was a problem hiding this comment.
Actionable comments posted: 1
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
pnpm-lock.yamlis excluded by!**/pnpm-lock.yaml
📒 Files selected for processing (4)
package.json(4 hunks)src/lib/domains/agentic/services/dependencies.json(1 hunks)src/test-utils/__tests__/event-bus.test.ts(1 hunks)src/test-utils/event-bus.ts(1 hunks)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (5)
- GitHub Check: Build
- GitHub Check: Tests - Phase 2 (React Components)
- GitHub Check: Tests - Phase 1 (Main Suite)
- GitHub Check: ESLint
- GitHub Check: Dependabot
🔇 Additional comments (5)
src/lib/domains/agentic/services/dependencies.json (1)
5-5: Dependency allowlist update looks good.Adding
"~/env"to the allowed dependencies is appropriate—it enables the agentic service to consume the newGENERATE_PREVIEW_MODELenvironment variable as described in the PR context. The entry follows the existing path-alias pattern and maintains the manifest's clarity.src/test-utils/__tests__/event-bus.test.ts (1)
3-3: LGTM! Import path update is consistent.The import path update aligns with the refactoring in
src/test-utils/event-bus.ts, consolidating event bus types in the dedicated types module.package.json (3)
17-18: New database maintenance scripts follow existing patterns.The orphan-finder and cleanup scripts are properly integrated with consistent naming, environment handling, and command structure matching existing db maintenance scripts.
156-157: Clarify the js-yaml override and vite override intent.The new js-yaml override properly enforces a minimum version, but the vite override needs clarification:
"vite@>=7.0.0": "6.3.5"forces Vite 7.x back to 6.3.5, which suggests a transitive dependency issue.- If this is intentional, it should be documented in a comment or commit message explaining why 7.x support is being declined.
121-123: Remove "contradiction" framing; the override is necessary but reveals an underlying compatibility issue.The pnpm override
"vite@>=7.0.0": "6.3.5"is not contradictory to the caret constraint^6.3.5. The override manages transitive dependencies (if any require vite ≥7.0.0) while the caret governs direct dependencies—both work together correctly.However, there is a real compatibility concern: vitest 2.1.9 supports Vite 3, 4, and 5 only, but package.json specifies vite 6.3.5. This violates vitest's peer dependency contract and may cause runtime issues. The override exists as a defensive measure but doesn't resolve the core incompatibility. Before proceeding, verify that vitest 2.1.9 and vite 6.3.5 are tested together in your environment, or consider upgrading to a Vitest version with Vite 6 support (vitest 3.x or later).
| @@ -1,5 +1,5 @@ | |||
| import { vi } from 'vitest'; | |||
| import type { AppEvent, EventListener, EventBusService } from '~/app/map'; | |||
| import type { AppEvent, EventListener, EventBusService } from '~/lib/utils/event-bus/types'; | |||
There was a problem hiding this comment.
🧩 Analysis chain
Import path refactoring looks good, but verify completeness.
The import path update from ~/app/map to ~/lib/utils/event-bus/types improves code organization by consolidating event bus type definitions in a dedicated module.
Run the following script to verify the refactoring is complete:
🏁 Script executed:
#!/bin/bash
# Verify the new types module exists and exports all required types
echo "=== Checking new types module ==="
fd -t f "types.ts" src/lib/utils/event-bus --exec cat {}
# Check for any remaining imports from the old path
echo -e "\n=== Checking for old import paths ==="
rg -n "from ['\"]~/app/map['\"]" --type ts
# Check if old export location still exists
echo -e "\n=== Checking old export location ==="
fd -t f -p "src/app/map" --exec echo "Found: {}"Length of output: 34681
Refactoring is incomplete—16+ files still import from the old path.
The update to src/test-utils/event-bus.ts is valid, but the refactoring itself was not completed. Multiple files throughout the codebase still import EventBusService (and related types) from ~/app/map instead of ~/lib/utils/event-bus/types:
src/test-utils/providers.tsx:6-7src/app/map/_components/MapUI.tsx:11src/app/map/_hooks/use-tile-select-for-chat.tsx:2src/app/map/Cache/Lifecycle/MutationCoordinator/use-mutation-operations.ts:10src/app/map/Cache/Lifecycle/MutationCoordinator/mutation-coordinator.ts:10src/app/map/Cache/Handlers/NavigationHandler/navigation-handler-factories.ts:6src/app/map/Cache/Handlers/NavigationHandler/navigation-handler.ts:5src/app/map/Cache/Handlers/NavigationHandler/_core/navigation-core.ts:6src/app/map/Canvas/canvas.tsx:25- And others
Update all remaining imports to use the new ~/lib/utils/event-bus/types path to complete the refactoring.
🤖 Prompt for AI Agents
In src/test-utils/event-bus.ts around line 2 and across the codebase (notably
src/test-utils/providers.tsx:6-7, src/app/map/_components/MapUI.tsx:11,
src/app/map/_hooks/use-tile-select-for-chat.tsx:2,
src/app/map/Cache/Lifecycle/MutationCoordinator/use-mutation-operations.ts:10,
src/app/map/Cache/Lifecycle/MutationCoordinator/mutation-coordinator.ts:10,
src/app/map/Cache/Handlers/NavigationHandler/navigation-handler-factories.ts:6,
src/app/map/Cache/Handlers/NavigationHandler/navigation-handler.ts:5,
src/app/map/Cache/Handlers/NavigationHandler/_core/navigation-core.ts:6,
src/app/map/Canvas/canvas.tsx:25 and other files), remaining imports still
reference the old ~/app/map path; update each import that currently pulls
EventBusService, AppEvent, EventListener, or related types from ~/app/map to
import from the new ~/lib/utils/event-bus/types path, run a project-wide search
for those type names to find any missed occurrences, update them to the new
path, and run type check/build to confirm no unresolved imports remain.
- Downgrade from Vite 6.4.1 to 5.4.21 for compatibility with vitest 2.1.9 - Keep vitest at 2.1.9 (Vite 6 requires vitest 4.x which has breaking changes) - Fix MCP server: remove unsupported 'description' field from Server constructor - Add pnpm override to prevent Vite 6+ installation - TypeScript type checking now passes 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
Replace logical OR (||) and conditional assignments with nullish coalescing operators (?? and ??=) across 9 files for better type safety and cleaner code. Changes: - Use ??= for singleton patterns and conditional initialization - Replace || with ?? for safer default value handling - Simplify conditional assignment patterns 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
1 participant
Summary by CodeRabbit
New Features
Chores
Bug Fixes
Tests