chore(deps): pin exact versions and require 3-day release age#4436
Merged
Conversation
Set bun install to exact=true and minimumReleaseAge=259200s so new releases must age 3 days before they can be installed. Pinned every workspace dependency to its currently-resolved exact version to prevent silent drift on `bun install`.
Contributor
📝 WalkthroughWalkthroughAcross 39 package.json files spanning the monorepo's apps and packages directories, plus bunfig.toml and root package.json, all dependencies and devDependencies are pinned to exact versions by removing caret (^) and tilde (~) range specifiers. Compatible packages are simultaneously upgraded to newer point releases. Bun is configured to enforce exact installation. ChangesDependency pinning and version upgrades
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ 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 |
Contributor
Greptile SummaryThis PR hardens the monorepo's dependency management by adding
Confidence Score: 4/5Safe to merge with the xterm beta upgrade in apps/web acknowledged — the change is broadly mechanical and the new Bun options are valid and well-documented. The vast majority of changes are straightforward caret-removal across the monorepo, and both new bunfig.toml options work as advertised. The two items worth a second look are the undeclared xterm v5→v6 beta upgrade in apps/web (outside the stated scope) and the pre-existing tiptap version fragmentation that is now frozen in place. Neither is a blocking issue, but the xterm change in particular should be explicitly confirmed as intentional before merge. apps/web/package.json (xterm beta upgrade) and apps/desktop/package.json (tiptap version spread)
|
| Filename | Overview |
|---|---|
| bunfig.toml | Adds exact = true and minimumReleaseAge = 259200 (3 days) — both are valid Bun install options that enforce exact pinning and a supply-chain age gate respectively. |
| package.json | Root workspace dotenv-cli and sherif devDependencies converted from caret ranges to exact versions; sherif also bumped from 1.10.0 to 1.11.0. |
| apps/web/package.json | All dependency ranges pinned; @xterm/xterm and @xterm/addon-fit upgraded beyond the semver ranges they declared (v5→v6 beta and 0.10→0.12 beta), which is outside the stated PR scope of "pinning currently-resolved exact versions". |
| apps/desktop/package.json | All ranges removed and pinned to resolved versions; tiptap version fragmentation (emoji@3.17.1, table@3.18.0 vs core@3.21.0) pre-dates this PR but is now permanently frozen. |
| bun.lock | Lockfile regenerated to reflect all exact-version pins across the monorepo; mechanically consistent with the package.json changes. |
Flowchart
%%{init: {'theme': 'neutral'}}%%
flowchart TD
A[Developer runs bun install] --> B{Package in lockfile?}
B -- Yes --> C[Install exact pinned version]
B -- No / New package --> D{minimumReleaseAge check\n≥ 3 days old?}
D -- Pass --> E[Resolve & pin exact version\nexact = true]
D -- Fail --> F[❌ Blocked — too new\n< 259200 seconds old]
E --> G[Write to bun.lock]
C --> H[Install from lockfile]
G --> H
Prompt To Fix All With AI
Fix the following 2 code review issues. Work through them one at a time, proposing concise fixes.
---
### Issue 1 of 2
apps/web/package.json:30-31
**Undeclared xterm upgrade to pre-release beta in production app**
The old `package.json` had `"@xterm/addon-fit": "^0.10.0"` and `"@xterm/xterm": "^5.5.0"`. Semver rules for `0.x` packages mean `^0.10.0` resolves at most to `<0.11.0`, and `^5.5.0` cannot resolve to a v6 release. These aren't "carets removed from the previously-resolved exact version" — they are deliberate upgrades to `6.1.0-beta.197` / `0.12.0-beta.197` beta pre-releases. The PR description only mentions pinning existing resolved versions, so this change is outside its stated scope. If the intent was to align `apps/web` with `apps/desktop`'s xterm beta versions, that should be called out explicitly, since consumers of the web app now depend on pre-release packages that may carry breaking changes.
### Issue 2 of 2
apps/desktop/package.json:118-121
**TipTap extension version fragmentation permanently locked in**
`@tiptap/core` and most extensions are now pinned to `3.21.0`, but `@tiptap/extension-emoji` is pinned to `3.17.1` (4 minor versions behind) and `@tiptap/extension-table*` are at `3.18.0`. These mismatches pre-date this PR, but they are now permanently frozen by `exact = true`. If tiptap introduced internal API changes between `3.17.x` and `3.21.x` — particularly for the `Extension` base class or the `suggest` API used by emoji — runtime errors could occur. Now is a good time to align all tiptap packages to the same version before they get harder to update.
Reviews (1): Last reviewed commit: "chore(deps): pin exact versions and requ..." | Re-trigger Greptile
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
Comment on lines
+30
to
+31
| "framer-motion": "12.38.0", | ||
| "geist": "1.7.0", |
Contributor
There was a problem hiding this comment.
The old package.json had "@xterm/addon-fit": "^0.10.0" and "@xterm/xterm": "^5.5.0". Semver rules for 0.x packages mean ^0.10.0 resolves at most to <0.11.0, and ^5.5.0 cannot resolve to a v6 release. These aren't "carets removed from the previously-resolved exact version" — they are deliberate upgrades to 6.1.0-beta.197 / 0.12.0-beta.197 beta pre-releases. The PR description only mentions pinning existing resolved versions, so this change is outside its stated scope. If the intent was to align apps/web with apps/desktop's xterm beta versions, that should be called out explicitly, since consumers of the web app now depend on pre-release packages that may carry breaking changes.
Prompt To Fix With AI
This is a comment left during a code review.
Path: apps/web/package.json
Line: 30-31
Comment:
**Undeclared xterm upgrade to pre-release beta in production app**
The old `package.json` had `"@xterm/addon-fit": "^0.10.0"` and `"@xterm/xterm": "^5.5.0"`. Semver rules for `0.x` packages mean `^0.10.0` resolves at most to `<0.11.0`, and `^5.5.0` cannot resolve to a v6 release. These aren't "carets removed from the previously-resolved exact version" — they are deliberate upgrades to `6.1.0-beta.197` / `0.12.0-beta.197` beta pre-releases. The PR description only mentions pinning existing resolved versions, so this change is outside its stated scope. If the intent was to align `apps/web` with `apps/desktop`'s xterm beta versions, that should be called out explicitly, since consumers of the web app now depend on pre-release packages that may carry breaking changes.
How can I resolve this? If you propose a fix, please make it concise.
Comment on lines
+118
to
+121
| "@tiptap/extension-code": "3.21.0", | ||
| "@tiptap/extension-code-block": "3.21.0", | ||
| "@tiptap/extension-code-block-lowlight": "3.21.0", | ||
| "@tiptap/extension-document": "3.21.0", |
Contributor
There was a problem hiding this comment.
@tiptap/core and most extensions are now pinned to 3.21.0, but @tiptap/extension-emoji is pinned to 3.17.1 (4 minor versions behind) and @tiptap/extension-table* are at 3.18.0. These mismatches pre-date this PR, but they are now permanently frozen by exact = true. If tiptap introduced internal API changes between 3.17.x and 3.21.x — particularly for the Extension base class or the suggest API used by emoji — runtime errors could occur. Now is a good time to align all tiptap packages to the same version before they get harder to update.
Prompt To Fix With AI
This is a comment left during a code review.
Path: apps/desktop/package.json
Line: 118-121
Comment:
**TipTap extension version fragmentation permanently locked in**
`@tiptap/core` and most extensions are now pinned to `3.21.0`, but `@tiptap/extension-emoji` is pinned to `3.17.1` (4 minor versions behind) and `@tiptap/extension-table*` are at `3.18.0`. These mismatches pre-date this PR, but they are now permanently frozen by `exact = true`. If tiptap introduced internal API changes between `3.17.x` and `3.21.x` — particularly for the `Extension` base class or the `suggest` API used by emoji — runtime errors could occur. Now is a good time to align all tiptap packages to the same version before they get harder to update.
How can I resolve this? If you propose a fix, please make it concise.
Contributor
🧹 Preview Cleanup CompleteThe following preview resources have been cleaned up:
Thank you for your contribution! 🎉 |
![cubic-dev-ai[bot]](https://avatars.githubusercontent.com/in/1082092?s=60&v=4){kind=small}
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Actionable comments posted: 3
♻️ Duplicate comments (14)
packages/ui/package.json (2)
84-84:⚠️ Potential issue | 🟠 Major | 🏗️ Heavy liftVerify Zod 4 breaking changes in UI package schemas.
Same as [apps/marketing/package.json:44], this package upgrades to Zod 4.3.6 with significant breaking changes. UI packages often define form schemas, so pay special attention to
.default(),.record(), and custom error messages.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@packages/ui/package.json` at line 84, The UI package was upgraded to Zod 4.3.6 which includes breaking changes; audit all schema usage in this package (search for Zod schema definitions, usages of .default(), .record(), .transform(), .refine(), and any custom error messages) and update them to the Zod 4 API: ensure .default() is used on schemas not on parsers where behavior changed, replace any legacy object-record patterns with z.record(valueSchema) for records, adapt custom error message shapes to the new issue format, and update any transform/refine callbacks to accept the new argument signatures; run unit/component tests and form validation flows to confirm no runtime validation regressions.
88-88:⚠️ Potential issue | 🔴 Critical | 🏗️ Heavy liftVerify Tailwind v4 breaking changes in UI components.
Same as [apps/marketing/package.json:48,58], this package uses Tailwind v4.2.2. UI packages are especially sensitive to the breaking changes (important modifier position, opacity utilities, CSS variable syntax).
Also applies to: 94-94
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@packages/ui/package.json` at line 88, The UI package currently depends on "@tailwindcss/postcss": "4.2.2" which is Tailwind v4 and may introduce breaking changes; verify and fix UI components to be compatible with Tailwind v4 by auditing components referenced in the UI package (and compare with apps/marketing occurrences) for the known breaking changes: important modifier position, opacity utility changes, and CSS variable syntax. Either downgrade/pin the dependency to a compatible v3.x release or follow Tailwind's migration steps: update tailwind.config.js and PostCSS config, adjust component classes where important modifiers are relocated, convert opacity/utilities usage to the new API, and fix CSS variable usages; run the UI build, storybook/tests, and visually inspect key components to confirm no regressions, then update the package.json dependency entry "@tailwindcss/postcss": "4.2.2" accordingly.apps/desktop/package.json (3)
209-209:⚠️ Potential issue | 🟠 Major | 🏗️ Heavy liftVerify React 19 breaking changes in desktop app.
Same as [packages/ui/package.json:92-93], React 19.2.0 has breaking changes affecting component patterns.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@apps/desktop/package.json` at line 209, The desktop app package.json declares "react": "19.2.0" which may introduce the same breaking changes as noted in packages/ui; audit and update desktop-specific components and dependencies to ensure React 19 compatibility: search for usages of legacy component patterns (e.g., render lifecycles, Suspense/SSR assumptions, and any unstable APIs) within the desktop app codebase, update affected components to the new React 19 APIs or adjust patterns, run the desktop app unit/integration tests and manual smoke tests, and if immediate fixes aren’t possible pin React to a compatible version or bump dependent packages (matching fixes made in packages/ui) until the code is updated.
242-242:⚠️ Potential issue | 🟠 Major | 🏗️ Heavy liftVerify Zod 4 breaking changes in desktop app.
Same as [apps/marketing/package.json:44], Zod 4.3.6 has breaking changes.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@apps/desktop/package.json` at line 242, The desktop app depends on "zod": "4.3.6", which may include breaking changes; update the dependency to a known-compatible version (or the same version used elsewhere if validated), then audit and fix any Zod API usages (e.g., calls to parse/safeParse, refine, transform, schema constructors) in the desktop codebase to match Zod v4 semantics; run the app's tests and compile to find failures, adjust schemas or calls accordingly, and lock the working zod version in package.json and package-lock/yarn.lock to prevent regressions.
271-271:⚠️ Potential issue | 🔴 Critical | 🏗️ Heavy liftVerify Tailwind v4 breaking changes in desktop app.
Same as [apps/marketing/package.json:48,58], Tailwind v4.2.2 has critical breaking changes.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@apps/desktop/package.json` at line 271, The package.json currently pins "tailwindcss": "4.2.2", which is a breaking v4 release; update the desktop app to a compatible Tailwind version or adapt the code to v4 breaking changes: either change the dependency to the previous safe version (e.g., v3.x) in package.json or audit and update Tailwind-related config and class usage (postcss/tailwind.config.js, any global CSS and component classnames) to comply with Tailwind v4 semantics; run a fresh install and the app build/test to confirm no regressions.apps/api/package.json (2)
51-51:⚠️ Potential issue | 🟠 Major | 🏗️ Heavy liftVerify Zod 4 breaking changes in API schemas.
Same as [apps/marketing/package.json:44], Zod 4.3.6 has breaking changes. API packages heavily use Zod for request/response validation, so thoroughly verify:
- Input validation schemas (
.record()now requires both key/value)- Response schemas with
.default()values- Custom error messages (now use unified
.error()parameter)🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@apps/api/package.json` at line 51, Upgrade of zod to 4.3.6 can break API validation; audit all request/response validation schemas that use Zod (search for usages of .record, .default, and .error) and update them: ensure every .record() call in your schema definitions provides both key and value schemas, update any schemas that rely on implicit defaults to use .default() correctly in response builders, and replace old custom message usages with the unified .error() parameter; run and fix failing tests for the API validation helpers (request validators, response serializers, and any middleware that calls these schemas) and update any examples or types that assume previous Zod behavior.
44-44:⚠️ Potential issue | 🟠 Major | 🏗️ Heavy liftVerify Next.js 16.2.1 async API changes in API routes.
Same as [apps/marketing/package.json:28], Next.js 16 requires async handling of request APIs. This is critical for API routes that use
cookies(),headers(), etc.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@apps/api/package.json` at line 44, The project upgraded to Next.js 16.2.1 which requires API route handlers that use cookies(), headers(), or other async request APIs to be async; update all API route exports (e.g., any functions named handler, default export handlers, or exported GET/POST functions) to be async, change synchronous signatures like function handler(req, res) to async function handler(req, res) or export async function GET/POST(request) as appropriate, and ensure any calls to cookies(), headers(), or Next Request helpers are awaited or used inside these async handlers (mirror the same fixes applied in apps/marketing package.json API routes).apps/admin/package.json (3)
40-40:⚠️ Potential issue | 🟠 Major | 🏗️ Heavy liftVerify Zod 4 breaking changes in admin app.
Same as [apps/marketing/package.json:44], Zod 4.3.6 has breaking changes.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@apps/admin/package.json` at line 40, The admin app's package.json pins "zod": "4.3.6", which may contain the same Zod v4 breaking changes noted in apps/marketing/package.json:44; verify compatibility by running the admin test suite and searching for usages of Zod APIs (e.g., schema.parse, safeParse, ZodType refinements, .optional/.nullable behaviors) and either update the consuming code to match Zod v4 semantics or rollback/pin "zod" to the previously working version (e.g., the version used by apps/marketing before the change); ensure package.json's "zod" entry is updated accordingly and re-run build/tests to confirm no runtime or type errors remain.
30-30:⚠️ Potential issue | 🟠 Major | 🏗️ Heavy liftVerify Next.js 16.2.1 async API changes.
Same as [apps/marketing/package.json:28], Next.js 16 requires async handling of request APIs.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@apps/admin/package.json` at line 30, Project's Next.js bumped to 16.2.1 which requires async Request/Response handling for route handlers; update the admin app to match the async API changes (same fix as apps/marketing). Locate any API route/route handlers (exported functions handling requests) and convert them to async functions that accept and return Web Request/Response objects (e.g., export default async function handler(req: Request) { ...; return new Response(...) } or use NextResponse), ensure any middleware or data fetching uses await and returns a Response, and adjust exports (default/edge runtime flags) as needed so all admin API endpoints comply with Next.js 16 async semantics.
50-50:⚠️ Potential issue | 🔴 Critical | 🏗️ Heavy liftVerify Tailwind v4 breaking changes.
Same as [apps/marketing/package.json:48,58], Tailwind v4.2.2 has critical breaking changes.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@apps/admin/package.json` at line 50, The package.json for apps/admin currently pins "tailwindcss": "4.2.2" which may introduce breaking changes; confirm consistency with apps/marketing package.json and either align versions or apply Tailwind v4 migration steps: locate the "tailwindcss": "4.2.2" entry in apps/admin/package.json (and the same key in apps/marketing/package.json), decide whether to downgrade/lock to the last known-compatible version used elsewhere or upgrade project code to comply with Tailwind v4 (update config, purge/content paths, and classnames per the Tailwind v4 migration guide), run a full build/test pass and update the package.json dependency to the chosen version.packages/auth/package.json (1)
47-47:⚠️ Potential issue | 🟠 Major | 🏗️ Heavy liftVerify Zod 4 breaking changes in auth schemas.
Same as [apps/marketing/package.json:44], Zod 4.3.6 has breaking changes. Auth packages use Zod for user input validation and credential schemas.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@packages/auth/package.json` at line 47, The project pins Zod to "4.3.6" which contains breaking changes affecting auth validation; review and update all auth-related schemas (e.g., any files exporting user/credentials schemas, functions like parse/safeParse or .transform/.refine usages) to be compatible with Zod v4 rules or change the dependency to a compatible Zod version. Specifically, scan for schema APIs that changed in Zod 4 (transform/refine return types, preprocess behavior, safeParse typings), run unit tests against auth validators, update schema code to use the new v4 APIs (adjust transforms/preprocess and validation error handling) or revert the dependency to a previously compatible version, and ensure package.json's "zod" entry and any import usages are consistent after the change.apps/mobile/package.json (2)
88-88:⚠️ Potential issue | 🔴 Critical | 🏗️ Heavy liftVerify Tailwind v4 breaking changes in mobile app.
Same as [apps/marketing/package.json:48,58], Tailwind v4.2.2 has critical breaking changes. Note that mobile styling may use different patterns than web.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@apps/mobile/package.json` at line 88, The mobile app's package.json currently pins "tailwindcss": "4.2.2" which may introduce breaking changes; either align the dependency with the working version used elsewhere (replace the "tailwindcss" entry with the same version string used in the other apps) or follow Tailwind v4 migration steps and update mobile-specific styles/components accordingly (inspect components using Tailwind classes and update tokens/utilities). After changing the version or code, run install + the mobile build/test suite to confirm no styling regressions.
91-91:⚠️ Potential issue | 🟠 Major | 🏗️ Heavy liftVerify Zod 4 breaking changes in mobile app schemas.
Same as [apps/marketing/package.json:44], Zod 4.3.6 has breaking changes.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@apps/mobile/package.json` at line 91, The mobile app now pins "zod": "4.3.6" which contains breaking changes; audit all Zod usages (search for imports from "zod" and calls to parse, safeParse, ZodObject/ZodEffects/ZodType) and apply the same schema adjustments you made in the other app: update schema definitions and any parsing/validation calls to the Zod 4 API, fix deprecated patterns, add/adjust safeParse handling, and run & update unit/integration tests to confirm schemas behave correctly under Zod 4.3.6.packages/host-service/package.json (1)
83-83:⚠️ Potential issue | 🟠 Major | 🏗️ Heavy liftVerify Zod 4 breaking changes in host service schemas.
Same as [apps/marketing/package.json:44], Zod 4.3.6 has breaking changes.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@packages/host-service/package.json` at line 83, package.json pins "zod": "4.3.6" which may introduce Zod v4 breaking changes; audit every schema that uses Zod (look for usages of z.object, z.array, z.enum, z.union, z.preprocess, z.transform, z.nativeEnum, etc.) and update schemas/tests to be compatible with Zod v4 semantics (adjust parsing/validation calls, refine types where z.optional/z.nullable behavior changed, replace deprecated helpers, and fix any .safeParse/.parse assumptions). Run the host service unit/integration tests and schema validation flows, update or add tests for failing schemas, and either fix the schemas or pin/upgrade Zod consistently across services to the intended major version to eliminate the break.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@apps/marketing/package.json`:
- Line 48: Tailwind v4 changed `outline-none` to only remove color; replace
usages with `outline-hidden` where full outline removal is intended. Update the
11 occurrences across the listed components—specifically in the RoadmapBoard
component (two spots in RoadmapBoard.tsx), PricingFAQ (PricingFAQ.tsx),
WaitlistModal (WaitlistModal.tsx), FAQSection (FAQSection.tsx),
ParallelExecutionDemo (ParallelExecutionDemo.tsx), EnterpriseFAQ
(EnterpriseFAQ.tsx), and the five places in EnterpriseContactForm
(EnterpriseContactForm.tsx)—by replacing the `outline-none` utility with
`outline-hidden` (or appropriate focused outline utility) to restore the prior
behavior. Ensure the change is applied to className strings/JSX props where
`outline-none` appears and run the app to verify no visual regressions.
- Line 44: Update the Zod error customization calls in
apps/marketing/src/lib/people.ts to the v4 API: replace positional string
messages passed to .min(...) with an options object using the message key (e.g.,
change .min(1, "Name is required") to .min(1, { message: "Name is required" })
and likewise change .min(1, "Role is required") to .min(1, { message: "Role is
required" })) so the validators (the .min calls in the people schema) are
compatible with Zod v4.3.6.
In `@bunfig.toml`:
- Line 4: minimumReleaseAge is currently placed at top-level in bunfig.toml
where Bun will ignore it; move the key into the [install] table by adding or
using the existing [install] section and placing minimumReleaseAge = 259200
under it so Bun recognizes the setting (reference: minimumReleaseAge key and the
[install] section in bunfig.toml).
---
Duplicate comments:
In `@apps/admin/package.json`:
- Line 40: The admin app's package.json pins "zod": "4.3.6", which may contain
the same Zod v4 breaking changes noted in apps/marketing/package.json:44; verify
compatibility by running the admin test suite and searching for usages of Zod
APIs (e.g., schema.parse, safeParse, ZodType refinements, .optional/.nullable
behaviors) and either update the consuming code to match Zod v4 semantics or
rollback/pin "zod" to the previously working version (e.g., the version used by
apps/marketing before the change); ensure package.json's "zod" entry is updated
accordingly and re-run build/tests to confirm no runtime or type errors remain.
- Line 30: Project's Next.js bumped to 16.2.1 which requires async
Request/Response handling for route handlers; update the admin app to match the
async API changes (same fix as apps/marketing). Locate any API route/route
handlers (exported functions handling requests) and convert them to async
functions that accept and return Web Request/Response objects (e.g., export
default async function handler(req: Request) { ...; return new Response(...) }
or use NextResponse), ensure any middleware or data fetching uses await and
returns a Response, and adjust exports (default/edge runtime flags) as needed so
all admin API endpoints comply with Next.js 16 async semantics.
- Line 50: The package.json for apps/admin currently pins "tailwindcss": "4.2.2"
which may introduce breaking changes; confirm consistency with apps/marketing
package.json and either align versions or apply Tailwind v4 migration steps:
locate the "tailwindcss": "4.2.2" entry in apps/admin/package.json (and the same
key in apps/marketing/package.json), decide whether to downgrade/lock to the
last known-compatible version used elsewhere or upgrade project code to comply
with Tailwind v4 (update config, purge/content paths, and classnames per the
Tailwind v4 migration guide), run a full build/test pass and update the
package.json dependency to the chosen version.
In `@apps/api/package.json`:
- Line 51: Upgrade of zod to 4.3.6 can break API validation; audit all
request/response validation schemas that use Zod (search for usages of .record,
.default, and .error) and update them: ensure every .record() call in your
schema definitions provides both key and value schemas, update any schemas that
rely on implicit defaults to use .default() correctly in response builders, and
replace old custom message usages with the unified .error() parameter; run and
fix failing tests for the API validation helpers (request validators, response
serializers, and any middleware that calls these schemas) and update any
examples or types that assume previous Zod behavior.
- Line 44: The project upgraded to Next.js 16.2.1 which requires API route
handlers that use cookies(), headers(), or other async request APIs to be async;
update all API route exports (e.g., any functions named handler, default export
handlers, or exported GET/POST functions) to be async, change synchronous
signatures like function handler(req, res) to async function handler(req, res)
or export async function GET/POST(request) as appropriate, and ensure any calls
to cookies(), headers(), or Next Request helpers are awaited or used inside
these async handlers (mirror the same fixes applied in apps/marketing
package.json API routes).
In `@apps/desktop/package.json`:
- Line 209: The desktop app package.json declares "react": "19.2.0" which may
introduce the same breaking changes as noted in packages/ui; audit and update
desktop-specific components and dependencies to ensure React 19 compatibility:
search for usages of legacy component patterns (e.g., render lifecycles,
Suspense/SSR assumptions, and any unstable APIs) within the desktop app
codebase, update affected components to the new React 19 APIs or adjust
patterns, run the desktop app unit/integration tests and manual smoke tests, and
if immediate fixes aren’t possible pin React to a compatible version or bump
dependent packages (matching fixes made in packages/ui) until the code is
updated.
- Line 242: The desktop app depends on "zod": "4.3.6", which may include
breaking changes; update the dependency to a known-compatible version (or the
same version used elsewhere if validated), then audit and fix any Zod API usages
(e.g., calls to parse/safeParse, refine, transform, schema constructors) in the
desktop codebase to match Zod v4 semantics; run the app's tests and compile to
find failures, adjust schemas or calls accordingly, and lock the working zod
version in package.json and package-lock/yarn.lock to prevent regressions.
- Line 271: The package.json currently pins "tailwindcss": "4.2.2", which is a
breaking v4 release; update the desktop app to a compatible Tailwind version or
adapt the code to v4 breaking changes: either change the dependency to the
previous safe version (e.g., v3.x) in package.json or audit and update
Tailwind-related config and class usage (postcss/tailwind.config.js, any global
CSS and component classnames) to comply with Tailwind v4 semantics; run a fresh
install and the app build/test to confirm no regressions.
In `@apps/mobile/package.json`:
- Line 88: The mobile app's package.json currently pins "tailwindcss": "4.2.2"
which may introduce breaking changes; either align the dependency with the
working version used elsewhere (replace the "tailwindcss" entry with the same
version string used in the other apps) or follow Tailwind v4 migration steps and
update mobile-specific styles/components accordingly (inspect components using
Tailwind classes and update tokens/utilities). After changing the version or
code, run install + the mobile build/test suite to confirm no styling
regressions.
- Line 91: The mobile app now pins "zod": "4.3.6" which contains breaking
changes; audit all Zod usages (search for imports from "zod" and calls to parse,
safeParse, ZodObject/ZodEffects/ZodType) and apply the same schema adjustments
you made in the other app: update schema definitions and any parsing/validation
calls to the Zod 4 API, fix deprecated patterns, add/adjust safeParse handling,
and run & update unit/integration tests to confirm schemas behave correctly
under Zod 4.3.6.
In `@packages/auth/package.json`:
- Line 47: The project pins Zod to "4.3.6" which contains breaking changes
affecting auth validation; review and update all auth-related schemas (e.g., any
files exporting user/credentials schemas, functions like parse/safeParse or
.transform/.refine usages) to be compatible with Zod v4 rules or change the
dependency to a compatible Zod version. Specifically, scan for schema APIs that
changed in Zod 4 (transform/refine return types, preprocess behavior, safeParse
typings), run unit tests against auth validators, update schema code to use the
new v4 APIs (adjust transforms/preprocess and validation error handling) or
revert the dependency to a previously compatible version, and ensure
package.json's "zod" entry and any import usages are consistent after the
change.
In `@packages/host-service/package.json`:
- Line 83: package.json pins "zod": "4.3.6" which may introduce Zod v4 breaking
changes; audit every schema that uses Zod (look for usages of z.object, z.array,
z.enum, z.union, z.preprocess, z.transform, z.nativeEnum, etc.) and update
schemas/tests to be compatible with Zod v4 semantics (adjust parsing/validation
calls, refine types where z.optional/z.nullable behavior changed, replace
deprecated helpers, and fix any .safeParse/.parse assumptions). Run the host
service unit/integration tests and schema validation flows, update or add tests
for failing schemas, and either fix the schemas or pin/upgrade Zod consistently
across services to the intended major version to eliminate the break.
In `@packages/ui/package.json`:
- Line 84: The UI package was upgraded to Zod 4.3.6 which includes breaking
changes; audit all schema usage in this package (search for Zod schema
definitions, usages of .default(), .record(), .transform(), .refine(), and any
custom error messages) and update them to the Zod 4 API: ensure .default() is
used on schemas not on parsers where behavior changed, replace any legacy
object-record patterns with z.record(valueSchema) for records, adapt custom
error message shapes to the new issue format, and update any transform/refine
callbacks to accept the new argument signatures; run unit/component tests and
form validation flows to confirm no runtime validation regressions.
- Line 88: The UI package currently depends on "@tailwindcss/postcss": "4.2.2"
which is Tailwind v4 and may introduce breaking changes; verify and fix UI
components to be compatible with Tailwind v4 by auditing components referenced
in the UI package (and compare with apps/marketing occurrences) for the known
breaking changes: important modifier position, opacity utility changes, and CSS
variable syntax. Either downgrade/pin the dependency to a compatible v3.x
release or follow Tailwind's migration steps: update tailwind.config.js and
PostCSS config, adjust component classes where important modifiers are
relocated, convert opacity/utilities usage to the new API, and fix CSS variable
usages; run the UI build, storybook/tests, and visually inspect key components
to confirm no regressions, then update the package.json dependency entry
"@tailwindcss/postcss": "4.2.2" accordingly.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 5cba3d6f-76d1-44df-a572-2570c9bb3466
⛔ Files ignored due to path filters (1)
bun.lockis excluded by!**/*.lock
📒 Files selected for processing (32)
apps/admin/package.jsonapps/api/package.jsonapps/desktop/package.jsonapps/docs/package.jsonapps/electric-proxy/package.jsonapps/marketing/package.jsonapps/mobile/package.jsonapps/relay/package.jsonapps/web/package.jsonbunfig.tomlpackage.jsonpackages/auth/package.jsonpackages/chat/package.jsonpackages/cli-framework/package.jsonpackages/cli/package.jsonpackages/db/package.jsonpackages/desktop-mcp/package.jsonpackages/email/package.jsonpackages/host-service/package.jsonpackages/local-db/package.jsonpackages/macos-process-metrics/package.jsonpackages/mcp-v2/package.jsonpackages/mcp/package.jsonpackages/panes/package.jsonpackages/port-scanner/package.jsonpackages/pty-daemon/package.jsonpackages/sdk/package.jsonpackages/shared/package.jsonpackages/trpc/package.jsonpackages/ui/package.jsonpackages/workspace-client/package.jsonpackages/workspace-fs/package.json
| "stripe-gradient": "1.0.1", | ||
| "three": "0.181.2", | ||
| "ua-parser-js": "2.0.9", | ||
| "zod": "4.3.6" |
Contributor
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Search for Zod schema patterns that may be affected by breaking changes
echo "=== Checking for number schemas that might rely on infinite values ==="
rg -nP --type=ts --type=tsx -C2 'z\.number\(\)'
echo "=== Checking for .default() usage that might need .prefault() ==="
rg -nP --type=ts --type=tsx -C2 '\.default\('
echo "=== Checking for record schemas (now require both key and value) ==="
rg -nP --type=ts --type=tsx -C2 'z\.record\('
echo "=== Checking for function schemas (redesigned API) ==="
rg -nP --type=ts --type=tsx -C2 'z\.function\('
echo "=== Checking for custom error messages (now use unified .error()) ==="
rg -nP --type=ts --type=tsx -C2 '\.(min|max|email|refine)\([^)]*message:'Repository: superset-sh/superset
Length of output: 553
🏁 Script executed:
#!/bin/bash
# First, find where Zod is imported/used
echo "=== Finding files that import Zod ==="
rg -l "from\s+['\"]zod['\"]|import.*zod" --type=ts
echo ""
echo "=== Checking for number schemas ==="
rg -nC2 'z\.number\(\)' --type=ts
echo ""
echo "=== Checking for .default() usage ==="
rg -nC2 '\.default\(' --type=ts | head -30
echo ""
echo "=== Checking for record schemas ==="
rg -nC2 'z\.record\(' --type=ts
echo ""
echo "=== Checking for function schemas ==="
rg -nC2 'z\.function\(' --type=ts
echo ""
echo "=== Checking for .refine() with message parameter ==="
rg -nC2 '\.refine\(' --type=ts | head -30Repository: superset-sh/superset
Length of output: 50376
🏁 Script executed:
#!/bin/bash
echo "=== Checking for .int() with non-safe integer constraints ==="
rg -n 'z\.number\(\).*\.int\(\)' --type=ts | grep -E '(Infinity|MAX_SAFE_INTEGER|MIN_SAFE_INTEGER)' | head -20
echo ""
echo "=== Checking for .default() usage patterns ==="
rg -nC1 '\.default\(' --type=ts | grep -A1 -B1 'number\|string\|boolean' | head -50
echo ""
echo "=== Checking for .record() usage ==="
rg -n 'z\.record\(' --type=ts
echo ""
echo "=== Checking for z.function() usage ==="
rg -n 'z\.function\(' --type=ts
echo ""
echo "=== Checking for custom error messages in validation ==="
rg -n '\.(min|max|email|refine|positive|int)\([^)]*,\s*{' --type=ts | head -20Repository: superset-sh/superset
Length of output: 4866
🏁 Script executed:
#!/bin/bash
echo "=== Checking for old Zod error syntax (message property) ==="
rg -n "message:\s*['\"]" --type=ts | grep -i "\.min\|\.max\|\.email\|\.refine" | head -20
echo ""
echo "=== Checking for .default() on fields that might receive undefined ==="
rg -n "\.default\(" --type=ts | grep -B2 "\.optional\|nullable\|nullish" | head -40
echo ""
echo "=== Checking if apps/marketing uses any Zod schemas ==="
find apps/marketing -name "*.ts" -o -name "*.tsx" | xargs grep -l "from.*zod\|import.*zod" 2>/dev/null
echo ""
echo "=== Checking the specific file under review ==="
cat -n apps/marketing/package.json | sed -n '40,50p'Repository: superset-sh/superset
Length of output: 4761
🏁 Script executed:
#!/bin/bash
echo "=== Checking apps/marketing/src/env.ts ==="
cat -n apps/marketing/src/env.ts
echo ""
echo "=== Checking apps/marketing/src/lib/people.ts ==="
cat -n apps/marketing/src/lib/people.tsRepository: superset-sh/superset
Length of output: 4257
Update error customization syntax in apps/marketing/src/lib/people.ts for Zod v4 compatibility.
Zod v4 changed the error customization API. Lines 9–10 use the old v3 syntax where error messages were passed as a second positional argument to validators. This will fail with Zod v4.3.6.
Update:
.min(1, "Name is required")
.min(1, "Role is required")
To:
.min(1, { message: "Name is required" })
.min(1, { message: "Role is required" })
Other Zod patterns in the codebase (record schemas, number constraints, default values) are already v4-compatible.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@apps/marketing/package.json` at line 44, Update the Zod error customization
calls in apps/marketing/src/lib/people.ts to the v4 API: replace positional
string messages passed to .min(...) with an options object using the message key
(e.g., change .min(1, "Name is required") to .min(1, { message: "Name is
required" }) and likewise change .min(1, "Role is required") to .min(1, {
message: "Role is required" })) so the validators (the .min calls in the people
schema) are compatible with Zod v4.3.6.
| "dotenv": "^17.3.1", | ||
| "tailwindcss": "^4.1.18", | ||
| "typescript": "^5.9.3" | ||
| "@tailwindcss/postcss": "4.2.2", |
Contributor
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Search for Tailwind v3 patterns incompatible with v4
echo "=== Checking for important modifier at start (now must be at end) ==="
rg -nP '![\w-]+' --glob '*.tsx' --glob '*.jsx' -C1
echo "=== Checking for removed opacity utilities ==="
rg -nP '\b(bg|text|border|ring)-opacity-\d+' --glob '*.tsx' --glob '*.jsx' -C1
echo "=== Checking for CSS variable bracket syntax ==="
rg -nP '\[--[\w-]+\]' --glob '*.tsx' --glob '*.jsx' -C1
echo "=== Checking for outline-none usage ==="
rg -nP '\boutline-none\b' --glob '*.tsx' --glob '*.jsx' -C1Repository: superset-sh/superset
Length of output: 50377
🏁 Script executed:
#!/bin/bash
# Search for Tailwind v3 patterns in marketing app only, excluding node_modules and build artifacts
cd apps/marketing
echo "=== Important modifiers at START (v3 syntax - must move to END) ==="
# Look for !classname patterns in className strings, data attributes, etc.
rg -nP '(?:className|class)=.*?"[^"]*!\w' --glob '*.tsx' --glob '*.jsx' --glob '*.ts' --glob '*.js' -C1
echo -e "\n=== Removed opacity utilities (bg-opacity-*, text-opacity-*, etc.) ==="
rg -nP '\b(bg|text|border|ring|shadow)-opacity-' --glob '*.tsx' --glob '*.jsx' --glob '*.ts' --glob '*.js' -C1
echo -e "\n=== CSS variable bracket syntax [--name] (should be (--name)) ==="
rg -nP '\[--[\w-]+\]' --glob '*.tsx' --glob '*.jsx' --glob '*.ts' --glob '*.js' -C1
echo -e "\n=== outline-none usage (should be outline-hidden for full removal) ==="
rg -nP '\boutline-none\b' --glob '*.tsx' --glob '*.jsx' --glob '*.ts' --glob '*.js' -C1Repository: superset-sh/superset
Length of output: 5692
Update outline-none usage for Tailwind CSS v4 compatibility.
Tailwind CSS v4.2.2 changes outline removal behavior: outline-none only removes the outline color but not the width. Use outline-hidden for full removal as in v3.
Found 11 instances in the marketing app:
src/app/roadmap/components/RoadmapBoard/RoadmapBoard.tsx(2 occurrences)src/app/pricing/components/PricingFAQ/PricingFAQ.tsxsrc/app/components/WaitlistModal/WaitlistModal.tsxsrc/app/components/FAQSection/FAQSection.tsxsrc/app/components/FeaturesSection/components/ParallelExecutionDemo/ParallelExecutionDemo.tsxsrc/app/enterprise/components/EnterpriseFAQ/EnterpriseFAQ.tsxsrc/app/enterprise/components/EnterpriseContactForm/EnterpriseContactForm.tsx(5 occurrences)
The other breaking changes mentioned (important modifier placement, opacity utilities, CSS variable bracket syntax) are not present in the marketing app codebase.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@apps/marketing/package.json` at line 48, Tailwind v4 changed `outline-none`
to only remove color; replace usages with `outline-hidden` where full outline
removal is intended. Update the 11 occurrences across the listed
components—specifically in the RoadmapBoard component (two spots in
RoadmapBoard.tsx), PricingFAQ (PricingFAQ.tsx), WaitlistModal
(WaitlistModal.tsx), FAQSection (FAQSection.tsx), ParallelExecutionDemo
(ParallelExecutionDemo.tsx), EnterpriseFAQ (EnterpriseFAQ.tsx), and the five
places in EnterpriseContactForm (EnterpriseContactForm.tsx)—by replacing the
`outline-none` utility with `outline-hidden` (or appropriate focused outline
utility) to restore the prior behavior. Ensure the change is applied to
className strings/JSX props where `outline-none` appears and run the app to
verify no visual regressions.
| [install] | ||
| linker = "isolated" # Prevent hoisting from resolving `path-scurry@2` to `lru-cache@6` (missing `LRUCache`), which breaks the `@superset/desktop` postinstall native rebuild. | ||
| exact = true | ||
| minimumReleaseAge = 259200 |
Contributor
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Verify minimumReleaseAge support in Bun documentation and configuration schema
# Check Bun's official configuration documentation
rg -i 'minimumReleaseAge|minimum.*release.*age|release.*age' --type md --max-count 5
# Check if bunfig.toml schema or validation exists in node_modules
fd -t f 'bunfig|bun.*config' node_modules/.bin node_modules/bun* 2>/dev/null | head -5
# Look for any existing usage or references in the codebase
rg 'minimumReleaseAge' --type toml --type json --type ts --type js -C 2Repository: superset-sh/superset
Length of output: 1585
🌐 Web query:
Is minimumReleaseAge a valid Bun configuration option in bunfig.toml?
💡 Result:
No, minimumReleaseAge is not a valid top-level Bun configuration option in bunfig.toml. It must be nested under the [install] section as install.minimumReleaseAge.[1][2][3] The official Bun documentation explicitly documents it this way: [install] minimumReleaseAge = 259200 (3 days in seconds).[1] Related options like minimumReleaseAgeExcludes are also under [install].[1][4] GitHub issues and docs confirm this usage, with no mention of a top-level minimumReleaseAge.[5][6]
Citations:
- 1: https://bun.com/docs/runtime/bunfig
- 2: https://bun.sh/docs/runtime/bunfig
- 3: https://bun.sh/docs/cli/install
- 4: Feaure Request: Support version-specific entries in minimumReleaseAgeExcludes for safer package whitelisting oven-sh/bun#28967
- 5: Bun update --latest does not respect minimumReleaseAge for transient dependencies oven-sh/bun#25305
- 6: Add support to minimumReleaseAge and minimumReleaseAgeExclude for
bun installoven-sh/bun#22679
Move minimumReleaseAge under the [install] section in bunfig.toml.
The minimumReleaseAge option is valid in Bun and correctly calculated (259200 seconds = 3 days), but it must be nested under the [install] section per official Bun documentation. It currently appears at the top level, where it will be ignored.
Correct format
[install]
minimumReleaseAge = 259200🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@bunfig.toml` at line 4, minimumReleaseAge is currently placed at top-level in
bunfig.toml where Bun will ignore it; move the key into the [install] table by
adding or using the existing [install] section and placing minimumReleaseAge =
259200 under it so Bun recognizes the setting (reference: minimumReleaseAge key
and the [install] section in bunfig.toml).
3 tasks
saddlepaddle
added a commit
that referenced
this pull request
May 13, 2026
Changes since alpha.9: - workspaces.list accepts `projectId`, `projectName`, and `search` to filter the listing — matches the desktop list view. (#4455) - chore(deps): pin exact dev versions (`bun-types` 1.3.11, `typescript` 5.9.3). (#4436) - BREAKING: `automations.create` / `automations.update` / `AutomationSummary` rename `agentConfig` -> `agent` (string id of a host agent instance or preset, e.g. `claude`, `codex`, `superset`). The `AgentConfig` type is removed from the public surface. The host now resolves the live agent config on every run, so client-side snapshots no longer drift from `Settings → Agents` edits. (#4481) After merge: `cd packages/sdk && bun run build && cd dist && npm publish --access public`.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
exact = trueandminimumReleaseAge = 259200(3 days) tobunfig.tomlsobun installwrites exact pins and refuses releases that are newer than 3 days oldpackage.jsonfiles to its currently-resolved exact version (carets removed)bun.lockto matchThe age gate is our defense against compromised-package supply-chain attacks: a malicious release has 3 days to be caught and yanked before any of our installs can pull it.
Test plan
bun run lintcleanbun run typecheckclean (29/29)Summary by cubic
Pins all dependencies to exact versions and enforces a 3‑day release age gate in
bun installto prevent silent version drift and reduce supply‑chain risk.Dependencies
exact = trueandminimumReleaseAge = 259200inbunfig.toml.package.jsonfiles and regeneratedbun.lock.Migration
bun installlocally; new releases published in the last 3 days will be rejected.Written for commit c173528. Summary will update on new commits.
Summary by CodeRabbit