fix(dashboard): expose column roles to browser bundle - #3151
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (2)
📝 WalkthroughWalkthroughThe PR adds a browser-safe ChangesColumn roles browser export
Estimated code review effort: 2 (Simple) | ~10 minutes Possibly related PRs
Suggested reviewers: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
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 |
|
Swept this with the inert-sync-lane check (wrapper-taint version from #3122): no change — it introduces no guard resolved through One forward-looking note, because this makes a specific trap more likely rather than less.
Making Worth a line in that note saying the roles are now importable but the per-neighbour requirement stands — otherwise the flag reads as blocked-on-tooling that has since been unblocked. That is the same shape as #3108 → #3114, where a correct warning was overwritten hours later by someone who reasonably believed the obstacle had moved. Not a blocker on this PR; the bundling change is sound and I would land it as-is. (Edited: an earlier version of this comment dropped the symbol name |
Summary
@fusion/core/column-rolessubpath@fusion/corealiasesTest plan
node scripts/check-no-node-only-core-imports-in-dashboard.mjsFUSION_DASHBOARD_DEEP=1 pnpm --filter @fusion/dashboard exec vitest run app/utils/__tests__/taskRevert.test.ts --pool=threads --maxWorkers=1pnpm --filter @fusion/core typecheckpnpm --filter @fusion/dashboard typecheckCI=true pnpm check:changesetspnpm buildSummary by CodeRabbit
Bug Fixes
Refactor
Chores