Fix: show the deprecation panel if it's an old project and v3#3113
Fix: show the deprecation panel if it's an old project and v3#3113matt-aitken merged 1 commit intomainfrom
Conversation
Without doing an expensive query we can’t tell if it’s definitely a v3 projects – like getting run counts. So let’s just assume if the project hasn’t been upgraded to v4 (by running dev/deploy CLI with v4) AND the project is older than the v4 release then it’s v3.
|
WalkthroughTwo files are modified to introduce date-based filtering for the V3 deprecation panel. The Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes 🚥 Pre-merge checks | ✅ 1 | ❌ 2❌ Failed checks (2 warnings)
✅ Passed checks (1 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches
🧪 Generate unit tests (beta)
Tip Issue Planner is now in beta. Read the docs and try it out! Share your feedback on Discord. 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 |
There was a problem hiding this comment.
🧹 Nitpick comments (2)
apps/webapp/app/presenters/OrganizationsPresenter.server.ts (1)
113-123:createdAtis redundant here — already present via the spread.
...fullProjectat line 114 already includescreatedAt. The explicit re-assignment on line 115 is a no-op; only theenvironmentsoverride (line 116) is needed to shadow the spread.♻️ Proposed cleanup
project: { ...fullProject, - createdAt: fullProject.createdAt, environments: sortEnvironments(🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@apps/webapp/app/presenters/OrganizationsPresenter.server.ts` around lines 113 - 123, The spread of fullProject already contains createdAt, so remove the redundant explicit assignment createdAt: fullProject.createdAt from the object literal and keep only the environments override; update the project construction where fullProject is spread (symbols: fullProject, createdAt, environments, sortEnvironments) so the result relies on the spread for createdAt and uses the existing environments override to shadow that field.apps/webapp/app/components/navigation/SideMenu.tsx (1)
655-657: MoveV4_RELEASE_DATEto module level; drop redundantnew Date()cast.Two nits on this block:
V4_RELEASE_DATEis re-instantiated on every render. As a fixed constant it belongs at module scope.projectCreatedAtis already typed asDate, sonew Date(projectCreatedAt)is a no-op wrapper.remix-typedjsonhandles a subset of native types (includingDate) and properly round-trips them through the Remix serialization boundary, so the defensive cast isn't needed.♻️ Proposed cleanup
+// Outside the component, at module scope: +const V4_RELEASE_DATE = new Date("2025-09-01"); + function V3DeprecationPanel({ ... }) { - // Only show for projects created before v4 was released - const V4_RELEASE_DATE = new Date("2025-09-01"); - const isLikelyV3 = isV3 && new Date(projectCreatedAt) < V4_RELEASE_DATE; + const isLikelyV3 = isV3 && projectCreatedAt < V4_RELEASE_DATE;🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@apps/webapp/app/components/navigation/SideMenu.tsx` around lines 655 - 657, Move the V4_RELEASE_DATE constant out of the SideMenu component to module scope and initialize it once (e.g., const V4_RELEASE_DATE = new Date("2025-09-01") at top-level), and remove the redundant new Date(...) wrapper when computing isLikelyV3 so it reads const isLikelyV3 = isV3 && projectCreatedAt < V4_RELEASE_DATE; — update references to V4_RELEASE_DATE and ensure projectCreatedAt is used as a Date directly in the isLikelyV3 computation (leave isV3 and isLikelyV3 names intact).
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Nitpick comments:
In `@apps/webapp/app/components/navigation/SideMenu.tsx`:
- Around line 655-657: Move the V4_RELEASE_DATE constant out of the SideMenu
component to module scope and initialize it once (e.g., const V4_RELEASE_DATE =
new Date("2025-09-01") at top-level), and remove the redundant new Date(...)
wrapper when computing isLikelyV3 so it reads const isLikelyV3 = isV3 &&
projectCreatedAt < V4_RELEASE_DATE; — update references to V4_RELEASE_DATE and
ensure projectCreatedAt is used as a Date directly in the isLikelyV3 computation
(leave isV3 and isLikelyV3 names intact).
In `@apps/webapp/app/presenters/OrganizationsPresenter.server.ts`:
- Around line 113-123: The spread of fullProject already contains createdAt, so
remove the redundant explicit assignment createdAt: fullProject.createdAt from
the object literal and keep only the environments override; update the project
construction where fullProject is spread (symbols: fullProject, createdAt,
environments, sortEnvironments) so the result relies on the spread for createdAt
and uses the existing environments override to shadow that field.
ℹ️ Review info
Configuration used: Repository UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
apps/webapp/app/components/navigation/SideMenu.tsxapps/webapp/app/presenters/OrganizationsPresenter.server.ts
📜 Review details
⏰ 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). (25)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (6, 8)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (7, 8)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (8, 8)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (2, 8)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (8, 8)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (1, 8)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (3, 8)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (4, 8)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (7, 8)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (6, 8)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (2, 8)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (5, 8)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (4, 8)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (5, 8)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (3, 8)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (1, 8)
- GitHub Check: units / packages / 🧪 Unit Tests: Packages (1, 1)
- GitHub Check: e2e / 🧪 CLI v3 tests (windows-latest - pnpm)
- GitHub Check: sdk-compat / Node.js 20.20 (ubuntu-latest)
- GitHub Check: sdk-compat / Cloudflare Workers
- GitHub Check: typecheck / typecheck
- GitHub Check: sdk-compat / Bun Runtime
- GitHub Check: sdk-compat / Deno Runtime
- GitHub Check: e2e / 🧪 CLI v3 tests (windows-latest - npm)
- GitHub Check: sdk-compat / Node.js 22.12 (ubuntu-latest)
🧰 Additional context used
📓 Path-based instructions (7)
**/*.{ts,tsx}
📄 CodeRabbit inference engine (.github/copilot-instructions.md)
**/*.{ts,tsx}: Use types over interfaces for TypeScript
Avoid using enums; prefer string unions or const objects instead
**/*.{ts,tsx}: Always import tasks from@trigger.dev/sdk, never use@trigger.dev/sdk/v3or deprecatedclient.defineJobpattern
Every Trigger.dev task must be exported and have a uniqueidproperty with no timeouts in the run function
Files:
apps/webapp/app/presenters/OrganizationsPresenter.server.tsapps/webapp/app/components/navigation/SideMenu.tsx
{packages/core,apps/webapp}/**/*.{ts,tsx}
📄 CodeRabbit inference engine (.github/copilot-instructions.md)
Use zod for validation in packages/core and apps/webapp
Files:
apps/webapp/app/presenters/OrganizationsPresenter.server.tsapps/webapp/app/components/navigation/SideMenu.tsx
**/*.{ts,tsx,js,jsx}
📄 CodeRabbit inference engine (.github/copilot-instructions.md)
Use function declarations instead of default exports
Import from
@trigger.dev/coreusing subpaths only, never import from root
Files:
apps/webapp/app/presenters/OrganizationsPresenter.server.tsapps/webapp/app/components/navigation/SideMenu.tsx
apps/webapp/app/**/*.{ts,tsx}
📄 CodeRabbit inference engine (.cursor/rules/webapp.mdc)
Access all environment variables through the
envexport ofenv.server.tsinstead of directly accessingprocess.envin the Trigger.dev webapp
Files:
apps/webapp/app/presenters/OrganizationsPresenter.server.tsapps/webapp/app/components/navigation/SideMenu.tsx
apps/webapp/**/*.{ts,tsx}
📄 CodeRabbit inference engine (.cursor/rules/webapp.mdc)
apps/webapp/**/*.{ts,tsx}: When importing from@trigger.dev/corein the webapp, use subpath exports from the package.json instead of importing from the root path
Follow the Remix 2.1.0 and Express server conventions when updating the main trigger.dev webappAccess environment variables via
envexport fromapps/webapp/app/env.server.ts, never useprocess.envdirectly
Files:
apps/webapp/app/presenters/OrganizationsPresenter.server.tsapps/webapp/app/components/navigation/SideMenu.tsx
**/*.ts
📄 CodeRabbit inference engine (.cursor/rules/otel-metrics.mdc)
**/*.ts: When creating or editing OTEL metrics (counters, histograms, gauges), ensure metric attributes have low cardinality by using only enums, booleans, bounded error codes, or bounded shard IDs
Do not use high-cardinality attributes in OTEL metrics such as UUIDs/IDs (envId, userId, runId, projectId, organizationId), unbounded integers (itemCount, batchSize, retryCount), timestamps (createdAt, startTime), or free-form strings (errorMessage, taskName, queueName)
When exporting OTEL metrics via OTLP to Prometheus, be aware that the exporter automatically adds unit suffixes to metric names (e.g., 'my_duration_ms' becomes 'my_duration_ms_milliseconds', 'my_counter' becomes 'my_counter_total'). Account for these transformations when writing Grafana dashboards or Prometheus queries
Files:
apps/webapp/app/presenters/OrganizationsPresenter.server.ts
**/*.{js,ts,jsx,tsx,json,md,yaml,yml}
📄 CodeRabbit inference engine (AGENTS.md)
Format code using Prettier before committing
Files:
apps/webapp/app/presenters/OrganizationsPresenter.server.tsapps/webapp/app/components/navigation/SideMenu.tsx
🧠 Learnings (1)
📚 Learning: 2026-02-11T16:37:32.429Z
Learnt from: matt-aitken
Repo: triggerdotdev/trigger.dev PR: 3019
File: apps/webapp/app/components/primitives/charts/Card.tsx:26-30
Timestamp: 2026-02-11T16:37:32.429Z
Learning: In projects using react-grid-layout, avoid relying on drag-handle class to imply draggability. Ensure drag-handle elements only affect dragging when the parent grid item is configured draggable in the layout; conditionally apply cursor styles based on the draggable prop. This improves correctness and accessibility.
Applied to files:
apps/webapp/app/components/navigation/SideMenu.tsx
🔇 Additional comments (1)
apps/webapp/app/components/navigation/SideMenu.tsx (1)
128-131: No action needed.MatchedProjectincludes thecreatedAtfield. TheOrganizationsPresenterexplicitly returnscreatedAton the project object (line 115 ofOrganizationsPresenter.server.ts), so thePickoperation inSideMenuProjectwill succeed without any type errors.
Without doing an expensive query we can’t tell if it’s definitely a v3 projects – like getting run counts.
So let’s just assume if the project hasn’t been upgraded to v4 (by running dev/deploy CLI with v4) AND the project is older than the v4 release then it’s v3.