chore: repo maintenance #1247
chore: repo maintenance #1247
Conversation
🦋 Changeset detectedLatest commit: 95b59f8 The changes in this PR will be included in the next version bump. This PR includes changesets to release 3 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
|
The latest updates on your projects. Learn more about Vercel for GitHub.
1 Skipped Deployment
|
WalkthroughMonorepo-wide dependency, packaging, and tooling updates; many example projects and UploadThing example integrations removed; added a React Router adapter and TanStack SSR integration for UploadThing; Tailwind/PostCSS style layering and package export modernizations; Vitest and CI adjustments. Changes
Sequence Diagram(s)sequenceDiagram
participant Server
participant getUtConfig as "getUtConfig()"
participant Router as "TanStack Router"
participant Global as "globalThis.__UPLOADTHING"
Note over Server,Router: Server-side dehydrate (SSR)
Server->>getUtConfig: extractRouterConfig(uploadRouter)
getUtConfig-->>Server: EndpointMetadata
Server->>Global: set __UPLOADTHING = EndpointMetadata (embed in dehydrated state)
Server->>Router: send dehydrated state to client
Note over Router,Global: Client-side hydrate
Router->>Global: read __UPLOADTHING (if present)
Router->>Router: restore uploadthingConfig into client router state
Estimated code review effort🎯 4 (Complex) | ⏱️ ~60–90 minutes Areas to focus during review:
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 ignored due to path filters (1)
📒 Files selected for processing (3)
✅ Files skipped from review due to trivial changes (2)
🧰 Additional context used🧠 Learnings (5)📚 Learning: 2024-11-11T20:32:20.335ZApplied to files:
📚 Learning: 2024-11-11T20:32:20.335ZApplied to files:
📚 Learning: 2024-11-11T20:32:20.334ZApplied to files:
📚 Learning: 2024-11-11T20:10:04.389ZApplied to files:
📚 Learning: 2024-11-11T19:59:56.512ZApplied to files:
🔇 Additional comments (1)
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: 3
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
packages/uploadthing/package.json (1)
196-200: Update tailwindcss peerDependency for stable v4.The peerDependency allows
^4.0.0-beta.0but the main dependency uses stable^4.1.18. Update to reflect:- "tailwindcss": "^3.0.0 || ^4.0.0-beta.0" + "tailwindcss": "^3.0.0 || ^4.0.0"This clarifies that stable Tailwind v4 is supported.
🧹 Nitpick comments (1)
examples/backend-adapters/package.json (1)
25-31: Consider movingtypescriptfromdependenciestodevDependenciesin this example
If TypeScript isn’t required at runtime (usually true), keeping it underdependenciesincreases install surface area unnecessarily.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (2)
examples/with-novel/app/_styles/CalSans-SemiBold.otfis excluded by!**/*.otfpnpm-lock.yamlis excluded by!**/pnpm-lock.yaml
📒 Files selected for processing (71)
.nvmrc(0 hunks)docs/package.json(3 hunks)examples/backend-adapters/client-react/package.json(1 hunks)examples/backend-adapters/client-vanilla/package.json(1 hunks)examples/backend-adapters/client-vue/package.json(1 hunks)examples/backend-adapters/package.json(1 hunks)examples/backend-adapters/server/package.json(2 hunks)examples/minimal-appdir/package.json(1 hunks)examples/minimal-astro-react/package.json(1 hunks)examples/minimal-expo/package.json(2 hunks)examples/minimal-pagedir/package.json(1 hunks)examples/minimal-solidstart/package.json(1 hunks)examples/minimal-sveltekit/package.json(1 hunks)examples/minimal-tanstack-start/package.json(1 hunks)examples/profile-picture/package.json(1 hunks)examples/with-clerk-appdir/package.json(1 hunks)examples/with-clerk-pagesdir/package.json(1 hunks)examples/with-clerk-react-router/package.json(1 hunks)examples/with-clerk-remix/package.json(1 hunks)examples/with-drizzle-appdir/package.json(1 hunks)examples/with-drizzle-pagesdir/package.json(1 hunks)examples/with-novel/.env.example(0 hunks)examples/with-novel/CHANGELOG.md(0 hunks)examples/with-novel/README.md(0 hunks)examples/with-novel/app/_styles/fonts.ts(0 hunks)examples/with-novel/app/_styles/globals.css(0 hunks)examples/with-novel/app/_styles/prosemirror.css(0 hunks)examples/with-novel/app/api/uploadthing/route.ts(0 hunks)examples/with-novel/app/layout.tsx(0 hunks)examples/with-novel/app/menu.tsx(0 hunks)examples/with-novel/app/page.tsx(0 hunks)examples/with-novel/app/providers.tsx(0 hunks)examples/with-novel/editor/extensions.ts(0 hunks)examples/with-novel/editor/index.tsx(0 hunks)examples/with-novel/editor/node-selector.tsx(0 hunks)examples/with-novel/editor/slash-command.tsx(0 hunks)examples/with-novel/editor/text-buttons.tsx(0 hunks)examples/with-novel/next-env.d.ts(0 hunks)examples/with-novel/next.config.js(0 hunks)examples/with-novel/package.json(0 hunks)examples/with-novel/postcss.config.cjs(0 hunks)examples/with-novel/tailwind.config.ts(0 hunks)examples/with-novel/tsconfig.json(0 hunks)examples/with-novel/ui/button.tsx(0 hunks)examples/with-novel/ui/command.tsx(0 hunks)examples/with-novel/ui/dialog.tsx(0 hunks)examples/with-novel/ui/popover.tsx(0 hunks)examples/with-novel/uploadthing/client.ts(0 hunks)examples/with-novel/uploadthing/novel-plugin.ts(0 hunks)examples/with-novel/uploadthing/server.ts(0 hunks)examples/with-react-image-crop/package.json(1 hunks)examples/with-serveractions/package.json(1 hunks)examples/with-tailwindcss/package.json(1 hunks)package.json(2 hunks)packages/expo/package.json(1 hunks)packages/mime-types/package.json(1 hunks)packages/nuxt/package.json(1 hunks)packages/react/package.json(1 hunks)packages/shared/package.json(1 hunks)packages/solid/package.json(1 hunks)packages/svelte/package.json(1 hunks)packages/uploadthing/package.json(1 hunks)packages/vue/package.json(1 hunks)playground-v6/package.json(2 hunks)playground/package.json(2 hunks)pnpm-workspace.yaml(0 hunks)tooling/eslint-config/package.json(1 hunks)tooling/eslint-plugin/package.json(1 hunks)tooling/gh-actions/setup/action.yml(1 hunks)tooling/tsconfig/package.json(1 hunks)tooling/vitest-config/package.json(1 hunks)
💤 Files with no reviewable changes (31)
- examples/with-novel/app/page.tsx
- examples/with-novel/app/_styles/prosemirror.css
- examples/with-novel/README.md
- examples/with-novel/app/providers.tsx
- examples/with-novel/editor/text-buttons.tsx
- examples/with-novel/CHANGELOG.md
- examples/with-novel/next.config.js
- examples/with-novel/ui/popover.tsx
- pnpm-workspace.yaml
- examples/with-novel/editor/extensions.ts
- examples/with-novel/app/menu.tsx
- examples/with-novel/.env.example
- examples/with-novel/app/api/uploadthing/route.ts
- examples/with-novel/tsconfig.json
- .nvmrc
- examples/with-novel/app/_styles/globals.css
- examples/with-novel/editor/index.tsx
- examples/with-novel/next-env.d.ts
- examples/with-novel/postcss.config.cjs
- examples/with-novel/ui/command.tsx
- examples/with-novel/package.json
- examples/with-novel/uploadthing/server.ts
- examples/with-novel/editor/slash-command.tsx
- examples/with-novel/app/layout.tsx
- examples/with-novel/uploadthing/client.ts
- examples/with-novel/uploadthing/novel-plugin.ts
- examples/with-novel/ui/button.tsx
- examples/with-novel/tailwind.config.ts
- examples/with-novel/app/_styles/fonts.ts
- examples/with-novel/ui/dialog.tsx
- examples/with-novel/editor/node-selector.tsx
🧰 Additional context used
🧠 Learnings (11)
📚 Learning: 2024-09-30T21:49:47.986Z
Learnt from: juliusmarminge
Repo: pingdotgg/uploadthing PR: 989
File: examples/minimal-tanstack-start/package.json:19-24
Timestamp: 2024-09-30T21:49:47.986Z
Learning: As of September 2024, TypeScript version 5.5.2 is available and valid.
Applied to files:
examples/minimal-tanstack-start/package.jsontooling/eslint-config/package.jsonexamples/with-drizzle-pagesdir/package.jsonexamples/backend-adapters/package.jsonexamples/with-clerk-pagesdir/package.jsonexamples/minimal-astro-react/package.jsonexamples/with-clerk-appdir/package.jsonexamples/with-react-image-crop/package.jsonexamples/with-drizzle-appdir/package.jsonexamples/with-serveractions/package.jsonexamples/minimal-pagedir/package.jsonpackages/mime-types/package.jsonexamples/minimal-appdir/package.jsonexamples/minimal-sveltekit/package.jsonplayground-v6/package.jsonpackage.json
📚 Learning: 2024-11-07T18:28:14.191Z
Learnt from: juliusmarminge
Repo: pingdotgg/uploadthing PR: 1046
File: playground/package.json:26-26
Timestamp: 2024-11-07T18:28:14.191Z
Learning: In `package.json`, the `typescript-eslint` package is correctly used and should not be replaced with `typescript-eslint/eslint-plugin` and `typescript-eslint/parser` in modern configurations.
Applied to files:
tooling/eslint-config/package.jsontooling/eslint-plugin/package.jsonpackages/solid/package.jsonpackages/mime-types/package.jsonplayground-v6/package.json
📚 Learning: 2024-11-11T20:32:22.092Z
Learnt from: markflorkowski
Repo: pingdotgg/uploadthing PR: 1046
File: playground-v6/package.json:21-28
Timestamp: 2024-11-11T20:32:22.092Z
Learning: As of November 2024, ESLint version 9.x is the current stable release, and version 8.x is end-of-life (EOL). When suggesting ESLint version changes, ensure recommendations reflect the current stable version.
Applied to files:
tooling/eslint-config/package.jsontooling/eslint-plugin/package.json
📚 Learning: 2024-11-07T18:28:00.237Z
Learnt from: juliusmarminge
Repo: pingdotgg/uploadthing PR: 1046
File: playground/package.json:8-8
Timestamp: 2024-11-07T18:28:00.237Z
Learning: In projects using ESLint v9, the `lint` script in `package.json` does not need to specify a path or pattern, as ESLint v9 uses a default path.
Applied to files:
tooling/eslint-config/package.jsontooling/eslint-plugin/package.json
📚 Learning: 2024-12-07T18:44:24.444Z
Learnt from: juliusmarminge
Repo: pingdotgg/uploadthing PR: 1090
File: docs/src/components/Code.tsx:135-137
Timestamp: 2024-12-07T18:44:24.444Z
Learning: In `docs/src/components/Code.tsx`, using type casts like `as any` is acceptable due to type mismatches between React 18 and 19. These casts will be addressed when the project upgrades to React 19.
Applied to files:
examples/with-drizzle-pagesdir/package.jsonexamples/with-clerk-pagesdir/package.jsonexamples/with-clerk-appdir/package.jsonexamples/with-react-image-crop/package.jsonexamples/with-drizzle-appdir/package.jsonexamples/with-serveractions/package.jsonexamples/minimal-pagedir/package.jsonexamples/minimal-appdir/package.jsonplayground-v6/package.json
📚 Learning: 2025-01-03T17:49:32.484Z
Learnt from: juliusmarminge
Repo: pingdotgg/uploadthing PR: 1099
File: packages/solid/src/utils/createFetch.ts:15-19
Timestamp: 2025-01-03T17:49:32.484Z
Learning: "createFetch" in packages/solid/src/utils/createFetch.ts is considered an internal function, so changes to its signature are not covered by semver guarantees.
Applied to files:
packages/solid/package.jsonexamples/with-serveractions/package.jsonexamples/minimal-solidstart/package.json
📚 Learning: 2024-11-21T23:47:38.115Z
Learnt from: markflorkowski
Repo: pingdotgg/uploadthing PR: 1061
File: docs/src/app/(docs)/file-routes/page.mdx:182-189
Timestamp: 2024-11-21T23:47:38.115Z
Learning: In `docs/src/app/(docs)/file-routes/page.mdx`, the Zod version requirement should remain as `>=3` and not be changed to `>=3.24`.
Applied to files:
examples/minimal-expo/package.json
📚 Learning: 2025-01-24T01:57:53.903Z
Learnt from: markflorkowski
Repo: pingdotgg/uploadthing PR: 1138
File: playground/package.json:27-27
Timestamp: 2025-01-24T01:57:53.903Z
Learning: When reviewing package versions, verify the latest version from the npm registry instead of making assumptions about version availability. Package versions can change frequently, and cached knowledge about versions can become outdated quickly.
Applied to files:
packages/react/package.jsonpackages/uploadthing/package.json
📚 Learning: 2024-11-11T20:32:20.334Z
Learnt from: markflorkowski
Repo: pingdotgg/uploadthing PR: 1046
File: playground-v6/package.json:5-10
Timestamp: 2024-11-11T20:32:20.334Z
Learning: In the `playground-v6` project, the `lint` script in `package.json` can be `"eslint"` without specifying the directory, as `eslint` defaults to `.`.
Applied to files:
playground-v6/package.json
📚 Learning: 2024-11-11T20:32:20.335Z
Learnt from: markflorkowski
Repo: pingdotgg/uploadthing PR: 1046
File: playground-v6/package.json:5-10
Timestamp: 2024-11-11T20:32:20.335Z
Learning: In the `playground-v6` project, the use of the experimental `--turbopack` flag is acceptable, and instability is expected.
Applied to files:
package.json
📚 Learning: 2024-11-11T19:59:56.512Z
Learnt from: markflorkowski
Repo: pingdotgg/uploadthing PR: 1046
File: playground-v6/app/layout.tsx:21-21
Timestamp: 2024-11-11T19:59:56.512Z
Learning: In the `playground-v6` project, using the Tailwind CSS CDN in `playground-v6/app/layout.tsx` is acceptable as it is a playground for testing purposes and not intended for production deployment.
Applied to files:
package.json
🔇 Additional comments (35)
packages/nuxt/package.json (1)
49-50: Verify Vite 7 and Vitest 4 compatibility with Nuxt module.Vite 7 now requires Node.js 20.19+, 22.12+, having dropped support for Node.js 18. Ensure the root
package.jsonengine constraint is updated accordingly. Additionally, confirm the Nuxt module works correctly with these major version bumps by running the dev and test workflows.examples/with-drizzle-appdir/package.json (1)
32-32: TypeScript minor version upgrade — LGTM.The bump to TypeScript 5.9.3 is a minor upgrade with no known breaking changes for this Next.js + React 19 setup. Verify that
npm run typecheckpasses.examples/minimal-pagedir/package.json (1)
22-22: TypeScript minor version upgrade — LGTM.examples/with-serveractions/package.json (1)
21-21: TypeScript minor version upgrade — LGTM.examples/minimal-astro-react/package.json (1)
26-26: TypeScript minor version upgrade — LGTM.examples/with-clerk-appdir/package.json (1)
30-30: TypeScript minor version upgrade — LGTM.examples/with-tailwindcss/package.json (1)
22-24: No action needed. The example code is already compatible with TailwindCSS v4. The code uses only standard utility classes (flex, gap, bg-slate-800, disabled:opacity-50, etc.) and CSS variables withvar()syntax, all of which are compatible with v4. No incompatible v3 patterns were found.Likely an incorrect or invalid review comment.
packages/expo/package.json (1)
54-57: Routine dev tooling updates; verify build process.The tsdown (0.14.1 → 0.17.3) and TypeScript (5.8.3 → 5.9.3) updates are compatible. The wait-on upgrade (8.0.1 → 9.0.3) is a minor version bump. Verify the build script (
npm run build) completes successfully with these versions.examples/backend-adapters/client-react/package.json (1)
19-21: SWC plugin and Vite versions are compatible; verify build behavior.@vitejs/plugin-react-swc v4.2.2 and Vite 7.2.7 are designed to work together. The version bumps align with current ecosystem practices. Verify that the build (
npm run build) and dev server (npm run dev) function correctly with these versions.examples/with-clerk-pagesdir/package.json (1)
30-30: Verify @clerk/nextjs compatibility with Next.js 15.5.8.TypeScript upgrade is safe, but confirm that @clerk/nextjs 6.9.6 is compatible with Next.js 15.5.8 and React 19.2.2. Clerk middleware should be tested to ensure auth flows work correctly.
packages/vue/package.json (1)
53-58: No breaking changes from Tailwind CSS v4 upgrade detected in source code. A search for old v3 syntax patterns (opacity utilities, important modifiers, CSS variable syntax) returned no results across the codebase. Thepackages/vue/tailwind.config.tsfile is in place, and the dependency bump is safe to merge.examples/minimal-solidstart/package.json (1)
26-28: The Tailwind CSS v4.1.18 update is safe for this example. The Solid.js starter uses only basic, v4-compatible Tailwind utilities (flex,flex-col,gap-4,p-8), with no old v3-specific syntax patterns.examples/minimal-appdir/package.json (1)
23-23: > Likely an incorrect or invalid review comment.examples/minimal-tanstack-start/package.json (1)
22-23: No action needed. Vite 7.2.7 is already configured and in use with @tanstack/react-start 1.121.32. The vite.config.ts properly imports and uses the tanstackStart plugin, indicating full compatibility. No verification or changes are required.Likely an incorrect or invalid review comment.
examples/minimal-expo/package.json (1)
19-21: Tailwind v4 + NativeWind: verify the Expo styling pipeline still works after the bump
Tailwind 4 has breaking changes (syntax + build pipeline). Since this example usesnativewind, please confirm the required Tailwind v4 migration steps for NativeWind are applied (and that the example builds/renders correctly). Also worth double-checking TRPC 11.8.0 upgrade doesn’t require any client config updates for this example.Also applies to: 48-52
packages/mime-types/package.json (1)
98-99: tsdown bump: ensure emitted files still match the existingexportsmap
Given the preciseexportsentries (./dist/index.d.cts, subpath folders, etc.), please verify[email protected]still produces the same filenames/paths duringpnpm -C packages/mime-types build.examples/with-drizzle-pagesdir/package.json (1)
33-33: TS 5.9.3 bump: runpnpm typecheckfor this example
Just a quick sanity check thatnext/drizzletypes still line up under TS 5.9.3.examples/with-react-image-crop/package.json (1)
23-23: TS 5.9.3 bump: confirmtypecheck+next buildstill passtooling/gh-actions/setup/action.yml (1)
10-15:node-version-file: package.jsononly works if the repo’spackage.jsondeclares Node in a setup-node-supported field
Please confirm CI is actually picking up the intended Node version (e.g., viaengines.nodeor whateveractions/setup-node@v4supports forpackage.jsonin your setup). If not, consider switching to a dedicated.node-version(or equivalent) file.packages/svelte/package.json (1)
51-60: Vite 7 + Tailwind 4: confirm SvelteKit toolchain compatibility and CSS build output
Since this is a double-major tooling jump, please verifypnpm -C packages/svelte buildandpnpm -C packages/svelte build:stylessucceed, and that the produceddist/styles.cssis correct under Tailwind v4.packages/solid/package.json (1)
121-132: wait-on 9 + tsup 8.5.1: verifydevandbuildflows didn’t change behavior
Givendevrelies onwait-onandtsup --watch, please sanity-checkpnpm -C packages/solid devandpnpm -C packages/solid buildafter these bumps.playground/package.json (1)
14-15: Version bumps look fine; please validate against Tailwind v4 + TS 5.9 + Effect updates.
Given Tailwind 4.x and TS/Vite ecosystem bumps can be breaking, please ensure this playground still builds/lints/typechecks after install (and that Tailwind v4 syntax/migrations are complete).Also applies to: 24-32
packages/shared/package.json (1)
45-46: Bumps are reasonable; double-check Vitest 4 / coverage / tsdown compatibility in CI.
Main risk here is Vitest 4 +@vitest/coverage-istanbulchanges affecting config defaults/reporting andtsdownaffecting builds—worth validatingpnpm test+pnpm buildfor this package and any CI coverage parsing.Also applies to: 49-63
examples/profile-picture/package.json (1)
36-46: Good dependency refresh; ensure Tailwind v4 migration is complete for this example.
After upgrading from Tailwind 4 beta to 4.1.x, please verify the example still renders correctly (notably any!modifier usage, opacity utilities, and config/import expectations).tooling/tsconfig/package.json (1)
9-12: Tooling bump is OK; verify@effect/language-service+ TS 5.9 behavior in editors/CI.
Given the large jump in@effect/language-service, it’s worth validating typechecking and any editor integration workflows that depend on it.packages/react/package.json (1)
87-102: Please re-run browser test tooling after the Vitest/MSW major bumps.
vitest/@vitest/browserto 4.x andvitest-browser-reactto 2.x (plusmswbump) are the most likely to need config adjustments—worth validating this package’s full test matrix (node + browser) before merging.playground-v6/package.json (1)
14-15: Looks good; please sanity-checktypecheck+lintwith TS 5.9 / eslint tooling.
Given the TS +typescript-eslintbumps, a quickpnpm -C playground-v6 typecheck && pnpm -C playground-v6 lintvalidation would de-risk this.Also applies to: 26-28
tooling/vitest-config/package.json (1)
11-18: High leverage bump—please confirm all downstream packages’ tests still pass on Vitest 4.
Since this is the shared Vitest config package, it’s worth validating a representative set of consumers (unit + browser) after the 4.x upgrade.docs/package.json (1)
15-16: Docs deps bump is fine; Tailwind 3 → 4 migration is the main risk—please verify styling + build.
Recommend validatingpnpm -C docs buildand doing a quick visual pass for any Tailwind v4 breaking changes (important modifier placement, removed opacity utilities, etc.).Also applies to: 24-25, 42-43, 46-47, 55-57
examples/backend-adapters/client-vanilla/package.json (1)
15-16: Dependency upgrades look good.TypeScript and Vite bumps are routine; no anticipated breaking changes.
tooling/eslint-plugin/package.json (1)
12-13: Point-release update for TypeScript ESLint packages.Routine version bump within v8.x; no anticipated breaking changes.
tooling/eslint-config/package.json (1)
15-22: ESLint tooling and TypeScript updated consistently.Point-release updates across TypeScript ESLint packages align with root TypeScript 5.9.3 upgrade; no breaking changes expected.
examples/with-clerk-remix/package.json (1)
28-28: No Tailwind v4 migration changes needed in example code.The example code already uses only standard Tailwind utilities that are compatible with both v3 and v4. There are no instances of deprecated v3 syntax such as
!modifiers, opacity utilities (bg-opacity-*), or legacy CSS variable syntax. The upgrade to Tailwind CSS v4 can be completed without requiring any modifications to this example's source code.Likely an incorrect or invalid review comment.
examples/backend-adapters/server/package.json (1)
37-37: No action required. The @types/express version is already properly aligned with express ^5.0.1, and @types/express 5.0.6 is a patch release designed for Express v5. Additionally, the fastify and h3 adapters are independent frameworks that do not depend on Express or its type definitions—only the express.ts adapter uses Express, and it employs standard Express v5 APIs that are fully supported by the current type definitions.packages/uploadthing/package.json (1)
178-194: Verify compatibility with multiple major version bumps.Several dependencies have significant major version upgrades that require verification:
@vitest/coverage-istanbul: 3.x → 4.0.15 (breaking changes in config API, reporter API, coverage remapping, and test signature)body-parser: 1.x → 2.2.1 (requires Node.js 18+, removes convenience middleware, changes req.body initialization behavior; also contains security fix for v2.2.0 DoS vulnerability)vitest: 3.x → 4.0.15 (multiple breaking changes: browser providers now separate packages, mock/spy API changes, removed config options like poolMatchGlobs/environmentMatchGlobs, custom reporter API updated, test option signature changed from test(name, fn, options) to test(name, options, fn))wait-on: 8.x → 9.0.3valibot: beta → 1.2.0 (major API changes: pipe-based composition replaces chaining, additionalProperties handling changed, force config renamed to errorMode, schema helpers and action names updated)Confirm that:
- Tests pass with vitest 4.x and the test signature changes are properly updated
- Express/server adapters work with body-parser 2.x and only use individual parsers (not removed convenience middleware)
- Code handles req.body being undefined instead of default {} in body-parser 2.x
- valibot validation pipelines follow the v1 API pattern (pipe-based, not chained)
- No other code depends on removed vitest config options (poolMatchGlobs, environmentMatchGlobs, deps.external/inline/fallbackCJS)
⛔ Skipped due to learnings
Learnt from: markflorkowski Repo: pingdotgg/uploadthing PR: 1138 File: playground/package.json:27-27 Timestamp: 2025-01-24T01:57:53.903Z Learning: When reviewing package versions, verify the latest version from the npm registry instead of making assumptions about version availability. Package versions can change frequently, and cached knowledge about versions can become outdated quickly.
| "typescript": "5.8.3", | ||
| "vite": "^6.3.4", | ||
| "postcss": "8.5.6", | ||
| "tailwindcss": "^4.1.18", |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
# Find the example directory structure
find examples/with-clerk-react-router -type f -name "*.tsx" -o -name "*.ts" -o -name "*.jsx" -o -name "*.js" -o -name "*.json" | grep -E "\.(tsx?|jsx?|json)$" | head -20Repository: pingdotgg/uploadthing
Length of output: 729
🏁 Script executed:
# Check if Tailwind config exists
find examples/with-clerk-react-router -name "tailwind.config.*" -o -name "postcss.config.*"Repository: pingdotgg/uploadthing
Length of output: 167
🏁 Script executed:
# Look at the main example files
ls -la examples/with-clerk-react-router/src/ 2>/dev/null || echo "src directory not found"Repository: pingdotgg/uploadthing
Length of output: 88
🏁 Script executed:
# Search for Tailwind CSS usage patterns (old v3 vs new v4 syntax)
rg -i "tailwind|@apply|@layer" examples/with-clerk-react-router --type tsx --type ts --type jsx --type js --type css -A 2Repository: pingdotgg/uploadthing
Length of output: 92
🏁 Script executed:
# Check the package.json to understand dependencies
cat examples/with-clerk-react-router/package.jsonRepository: pingdotgg/uploadthing
Length of output: 1012
🏁 Script executed:
cat examples/with-clerk-react-router/tailwind.config.tsRepository: pingdotgg/uploadthing
Length of output: 248
🏁 Script executed:
cat examples/with-clerk-react-router/postcss.config.jsRepository: pingdotgg/uploadthing
Length of output: 123
🏁 Script executed:
cat -n examples/with-clerk-react-router/app/root.tsxRepository: pingdotgg/uploadthing
Length of output: 1355
🏁 Script executed:
cat -n examples/with-clerk-react-router/app/routes/_index.tsxRepository: pingdotgg/uploadthing
Length of output: 1677
🏁 Script executed:
# Search for CSS files that might contain Tailwind directives
find examples/with-clerk-react-router -name "*.css" -o -name "*.scss"Repository: pingdotgg/uploadthing
Length of output: 114
🏁 Script executed:
cat examples/with-clerk-react-router/app/tailwind.cssRepository: pingdotgg/uploadthing
Length of output: 586
🌐 Web query:
Tailwind CSS v4 breaking changes migration guide
💡 Result:
Below is a concise migration checklist for upgrading projects from Tailwind CSS v3 → v4, with the most important breaking changes and the minimal steps to fix them.
Quick upgrade steps
- Run the official upgrade tool in a new Git branch: npx @tailwindcss/upgrade (review diffs & test). (v3.tailwindcss.com)
- Ensure Node.js ≥ 20 (upgrade tool requirement). (twcss.cn)
- Update build packages: switch PostCSS plugin to @tailwindcss/postcss, Tailwind CLI to @tailwindcss/cli, and (if using Vite) use @tailwindcss/vite plugin. Adjust build scripts accordingly. (twcss.cn)
Major breaking changes you need to know (and how to fix)
- Configuration: tailwind.config.js → CSS-first configuration using CSS variables; many theme values are exposed as CSS vars. Prefer var(--color-...) over theme() where possible. For rare cases keep theme() but use the CSS variable names. (tailwindcss.com)
- Importing: The old @tailwind base/components/utilities directives are removed — import Tailwind via a normal CSS @import (upgrade tool will help). (tailwindcss.com)
- Package split: tailwindcss PostCSS plugin moved to @tailwindcss/postcss; Tailwind CLI moved to @tailwindcss/cli; update dependencies and build setups. (twcss.cn)
- Browser support: v4 targets modern browsers (e.g., Safari 16.4+, Chrome 111+, Firefox 128+); if you must support older browsers, stay on v3.4 or use compatibility strategies. (tailwindcss.com)
- Removed/renamed utilities:
- outline-none renamed to outline-hidden; outline-none now sets outline-style:none — search & replace usages. (tailwindcss.com)
- Default ring size changed from 3px → 1px; replace plain ring with ring-3 if you relied on old size. (tailwindcss.com)
- Space utilities: space-x/y selector changed (performance fix). If you used them with inline children or custom margins, consider switching to gap (flex/grid) or adjust markup. (tailwindcss.com)
- Transitions: transition-[...transform] no longer works for transformed utilities; use explicit properties like transition-[opacity,scale] when transitioning scale. (tailwindcss.com)
- corePlugins: Disabling core plugins via corePlugins option is no longer supported — remove or replace any logic depending on this. (tailwindcss.com)
Other notes and recommendations
- Use the upgrade tool to automate the bulk of changes, then manually review for app-specific edge cases (complex configs, plugins, or dynamic class generation). (v3.tailwindcss.com)
- Update any third‑party libraries (Nativewind, plugins, component libs) that reference v3 classnames or internals. (nativewind.dev)
- Test visually across pages (esp. forms, focus outlines, ring sizes, spacing, and transition effects).
Primary sources
- Tailwind upgrade guide / v4 docs (breaking changes + migration tool). (tailwindcss.com)
- Manual migration notes (PostCSS/Vite/CLI changes). (twcss.cn)
If you want, I can:
- run npx @tailwindcss/upgrade for you in a sample repo (show the expected diff), or
- scan your project files (tailwind.config.js and a few sample templates) and produce an itemized list of replacements to make. Which would you like?
Citations:
- 1: https://v3.tailwindcss.com/docs/v4-beta?utm_source=openai
- 2: https://www.twcss.cn/docs/upgrade-guide?utm_source=openai
- 3: https://www.twcss.cn/docs/upgrade-guide?utm_source=openai
- 4: https://tailwindcss.com/docs/upgrade-guide?utm_source=openai
- 5: https://tailwindcss.com/docs/upgrade-guide?utm_source=openai
- 6: https://www.twcss.cn/docs/upgrade-guide?utm_source=openai
- 7: https://tailwindcss.com/docs/upgrade-guide?utm_source=openai
- 8: https://tailwindcss.com/docs/upgrade-guide?utm_source=openai
- 9: https://tailwindcss.com/docs/upgrade-guide?utm_source=openai
- 10: https://tailwindcss.com/docs/upgrade-guide?utm_source=openai
- 11: https://tailwindcss.com/docs/upgrade-guide?utm_source=openai
- 12: https://tailwindcss.com/docs/upgrade-guide?utm_source=openai
- 13: https://v3.tailwindcss.com/docs/v4-beta?utm_source=openai
- 14: https://www.nativewind.dev/v5/guides/migrate-from-v4?utm_source=openai
- 15: https://tailwindcss.com/docs/upgrade-guide?utm_source=openai
- 16: https://www.twcss.cn/docs/upgrade-guide?utm_source=openai
🏁 Script executed:
# Check the with-clerk-remix example for comparison
cat examples/with-clerk-remix/app/tailwind.cssRepository: pingdotgg/uploadthing
Length of output: 586
🏁 Script executed:
# Verify if this is a widespread pattern
find examples -name "tailwind.css" -exec echo "=== {} ===" \; -exec head -5 {} \;Repository: pingdotgg/uploadthing
Length of output: 309
Update Tailwind CSS v4 syntax in source files.
The example uses Tailwind CSS v4.1.18 but the CSS file still contains the v3 @tailwind directives which are removed in v4. Replace @tailwind base; @tailwind components; @tailwind utilities; with @import "tailwindcss"; in app/tailwind.css. Additionally, update postcss.config.js to use the v4 PostCSS plugin: change the tailwindcss plugin to @tailwindcss/postcss.
🤖 Prompt for AI Agents
In examples/with-clerk-react-router/package.json around line 29 and related
project files, the project depends on Tailwind CSS v4 but source files still use
v3 syntax; update app/tailwind.css to replace the removed v3 @tailwind
directives with the v4 import syntax by replacing the three directives with
@import "tailwindcss"; and update postcss.config.js to use the v4 PostCSS plugin
by replacing the current "tailwindcss" plugin entry with "@tailwindcss/postcss"
(ensure package.json dependency remains ^4.1.18 and run install to pick up the
v4 PostCSS plugin if missing).
package.json
Outdated
| "node": "^24.10.0", | ||
| "pnpm": "^10.24.0" |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
# Check the git diff for package.json to see what changed
git diff HEAD~1 HEAD -- package.json | head -50Repository: pingdotgg/uploadthing
Length of output: 93
🏁 Script executed:
# If that doesn't show it, let's look at the recent history
git log --oneline -10 -- package.jsonRepository: pingdotgg/uploadthing
Length of output: 75
🏁 Script executed:
# Get the previous version of package.json to see the old constraint
git show HEAD~1:package.json | head -20Repository: pingdotgg/uploadthing
Length of output: 101
🏁 Script executed:
# Get the full package.json to see the context
cat package.jsonRepository: pingdotgg/uploadthing
Length of output: 1830
🏁 Script executed:
# Search for any documentation or comments about Node.js version requirements
rg -i "node.*24|node.*version" --type md --type mdx --type txtRepository: pingdotgg/uploadthing
Length of output: 92
🏁 Script executed:
# Check if there's a migration guide or changelog
fd -t f -e md -e mdx -e txt | xargs grep -l -i "node.js.*24\|breaking.*change" 2>/dev/null | head -20Repository: pingdotgg/uploadthing
Length of output: 275
🏁 Script executed:
# Check v7 documentation for breaking changes
cat docs/src/app/\(docs\)/v7/page.mdx | head -200Repository: pingdotgg/uploadthing
Length of output: 7148
🏁 Script executed:
# Search CHANGELOG files for Node.js version mentions
rg -i "node\s*24|node.*version|engine" packages/uploadthing/CHANGELOG.md packages/react/CHANGELOG.mdRepository: pingdotgg/uploadthing
Length of output: 47
🏁 Script executed:
# Check if there's a root CHANGELOG
fd -t f -e md | xargs grep -l -i "node.*24\|^##.*v7" | head -10Repository: pingdotgg/uploadthing
Length of output: 47
🏁 Script executed:
# Check for .nvmrc file
fd -name ".nvmrc" -o -name ".node-version"Repository: pingdotgg/uploadthing
Length of output: 295
🏁 Script executed:
# Check GitHub Actions workflow files for Node.js version
fd -path "*/.github/workflows/*" -type f | xargs cat 2>/dev/null | grep -i "node\|24" | head -30Repository: pingdotgg/uploadthing
Length of output: 233
🏁 Script executed:
# Search for any documentation about Node.js requirements
rg -i "node.*version|requires?.*node" --type md | head -20Repository: pingdotgg/uploadthing
Length of output: 47
🏁 Script executed:
# Check if there's a README that mentions Node.js requirements
cat README.md 2>/dev/null | head -100Repository: pingdotgg/uploadthing
Length of output: 2677
🏁 Script executed:
# Look for GitHub workflows
find .github/workflows -type f -name "*.yml" -o -name "*.yaml" 2>/dev/null | head -5Repository: pingdotgg/uploadthing
Length of output: 227
🏁 Script executed:
# Check one of the workflow files
cat .github/workflows/ci.yml 2>/dev/null | grep -A5 -B5 "node\|24" | head -50Repository: pingdotgg/uploadthing
Length of output: 47
🏁 Script executed:
# Search for any documentation about v7 requirements
rg "node.*24|version.*24" --type mdRepository: pingdotgg/uploadthing
Length of output: 47
🏁 Script executed:
# Read the CI workflow file
cat .github/workflows/ci.yamlRepository: pingdotgg/uploadthing
Length of output: 3563
🏁 Script executed:
# Check the custom GitHub Actions setup
cat ./tooling/gh-actions/setup/action.yml 2>/dev/null || cat ./tooling/gh-actions/setup.yml 2>/dev/null || find ./tooling/gh-actions -name "action.yml" -o -name "action.yaml"Repository: pingdotgg/uploadthing
Length of output: 671
Node.js engine constraint requires Node.js 24.10.0+, contradicting the README.
The engines.node constraint is set to ^24.10.0 (>=24.10.0, <25.0.0), which enforces Node.js 24 specifically. However, the README states contributors should "Ensure you have the LTS version of Node.js installed," and Node.js 24 is not an LTS version—only versions 20 and 22 are LTS. This is a restrictive constraint that drops support for earlier versions. Either update the README to reflect the Node.js 24 requirement, or document why Node.js 24 is required for v7 in the migration guide.
🤖 Prompt for AI Agents
In package.json around lines 6-7, the engines.node value "^24.10.0" conflicts
with the README which asks contributors to use an LTS Node (20/22); either relax
or change the engines constraint to match supported LTS versions (for example
set a range that includes LTS like ">=20 <25" or enumerate supported majors like
"^20 || ^22 || ^24"), or keep the strict "^24.10.0" but update the README and
migration guide to state that v7 requires Node 24 and explain why; implement one
of those two fixes consistently across package.json and documentation.
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (1)
packages/uploadthing/src/tw/index.ts (1)
49-51: Defensive initialization looks good, but consider extra safety forfilesproperty.The nullish coalescing assignment correctly handles the case where
contentis undefined or null. However, for maximum defensive coding, you might consider also ensuringcontent.filesis initialized:twConfig.content ??= { files: [] }; twConfig.content.files ??= []; twConfig.content.files.push(...contentPaths);This would guard against edge cases where
contentis an object without afilesproperty (though TypeScript types should prevent this).
📜 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 (8)
packages/mime-types/tsdown.config.ts(1 hunks)packages/react/package.json(2 hunks)packages/react/tsdown.config.ts(1 hunks)packages/svelte/package.json(1 hunks)packages/uploadthing/src/tw/index.ts(2 hunks)packages/uploadthing/src/tw/plugin.ts(2 hunks)packages/uploadthing/tsdown.config.ts(1 hunks)packages/vue/package.json(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (2)
- packages/react/package.json
- packages/vue/package.json
🧰 Additional context used
🧠 Learnings (1)
📚 Learning: 2024-11-05T17:11:33.300Z
Learnt from: juliusmarminge
Repo: pingdotgg/uploadthing PR: 1013
File: packages/mime-types/package.json:24-69
Timestamp: 2024-11-05T17:11:33.300Z
Learning: In this codebase, the bundler `bunchee` uses `package.json` as the source of truth for exports and outputs matching files during the build process. Therefore, the export paths specified in `package.json` align with the generated build output, even if the source files are located in a `src/` directory.
Applied to files:
packages/react/tsdown.config.tspackages/mime-types/tsdown.config.tspackages/uploadthing/tsdown.config.ts
🧬 Code graph analysis (2)
packages/uploadthing/src/tw/plugin.ts (2)
packages/uploadthing/src/tw/index.ts (1)
uploadthingPlugin(6-6)packages/uploadthing/src/tw/index.browser.ts (1)
uploadthingPlugin(5-5)
packages/uploadthing/src/tw/index.ts (1)
packages/uploadthing/src/tw/index.browser.ts (1)
withUt(7-12)
🔇 Additional comments (12)
packages/uploadthing/src/tw/index.ts (1)
19-19: LGTM: Explicit return type improves type safety.Adding the explicit
: Configreturn type annotation enhances API clarity and type safety without any behavioral changes.packages/uploadthing/src/tw/plugin.ts (1)
1-9: LGTM: Type safety improvements enhance plugin structure.The added type definitions (
PluginFn,PluginWithConfig) and explicit type annotations align well with Tailwind's plugin architecture. These changes improve type safety and developer experience without any behavioral modifications.Also applies to: 19-19
packages/mime-types/tsdown.config.ts (2)
14-19: Clarify the rationale forclean: false.Setting
clean: falsemeans tsdown will not remove old build artifacts before generating new ones. This can lead to stale files accumulating in the output directories if entry points are renamed or removed.Consider whether auto-cleanup is desired, or if there's a specific reason to preserve old files between builds (e.g., external tooling that references them).
5-11: No action required—package.json exports are correctly aligned with the tsdown entry structure. The main entry maps todist/indexand category entries (application, audio, image, text, video) map to their respective category paths, matching the configured outputs.packages/uploadthing/tsdown.config.ts (1)
21-26: Clarify the rationale forclean: false.Same concern as in the other packages: setting
clean: falseprevents automatic cleanup of old build artifacts, which can lead to stale files if entry points change.packages/react/tsdown.config.ts (3)
18-23: Clarify the rationale forclean: false.Setting
clean: falsehas implications for theonSuccesshook behavior. Line 25 usesopts.clean.length === 0to detect development mode, which assumescleanis alwaysfalsein dev. Verify this logic is intentional and document the relationship betweenclean: falseand the dev mode detection.
24-34: Verify the CSS output path is correct with the new configuration.The Tailwind CSS transpilation outputs to
./dist/index.css(line 31). With the new entry structure where the main entry is"dist/index", ensure this CSS file location aligns with how the package expects to export/consume it.
9-12: Ensure package.json exports are coordinated with the tsdown entry keys.The entry configuration specifies
"dist/index"for the main export and"native/index","next-ssr-plugin/index"for subpaths. Since package.json is the source of truth for build outputs, verify that theexportsfield correctly maps".","./native", and"./next-ssr-plugin"to their respective generated files.packages/svelte/package.json (4)
52-52: Minor version bumps look appropriate.The PostCSS 8.4.49→8.5.6 and TypeScript 5.8.3→5.9.3 updates are minor version bumps with low risk of breaking changes. These align with typical maintenance practices.
Also applies to: 58-58
52-52: Minor version bumps are appropriate.The PostCSS 8.4.49→8.5.6 and TypeScript 5.8.3→5.9.3 updates are low-risk minor/patch version bumps consistent with maintenance practices.
Also applies to: 58-58
49-49: Tailwind CSS v4 upgrade appears complete.The Svelte package components already use Tailwind v4-compatible syntax throughout (no old v3 opacity utilities, modern modifier placement, v4-specific features like
data-[state=...]selectors). The build:styles script should work correctly with the v4 CLI. No evidence of incomplete migration in the component files.
60-60: @sveltejs/vite-plugin-svelte@^5.0.3 is incompatible with Vite v7.Vite v7 requires @sveltejs/vite-plugin-svelte v6.x or newer (which added peer dependency support for ^6.3.0 || ^7.0.0). The current version must be upgraded to v6 to avoid build failures. Additionally, Vite v7 requires Node.js ≥20.19 or ≥22.12 (drops Node 18 support)—ensure CI and developer environments meet this requirement.
⛔ Skipped due to learnings
Learnt from: markflorkowski Repo: pingdotgg/uploadthing PR: 1138 File: playground/package.json:27-27 Timestamp: 2025-01-24T01:57:53.903Z Learning: When reviewing package versions, verify the latest version from the npm registry instead of making assumptions about version availability. Package versions can change frequently, and cached knowledge about versions can become outdated quickly.
📦 Bundle size comparison
|
More templates
@uploadthing/expo
@uploadthing/mime-types
@uploadthing/nuxt
@uploadthing/react
@uploadthing/shared
@uploadthing/solid
@uploadthing/svelte
uploadthing
@uploadthing/vue
commit: |
There was a problem hiding this comment.
Actionable comments posted: 2
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
packages/uploadthing/package.json (1)
199-199: Update tailwindcss peerDependency range to include stable v4.The peerDependency range for tailwindcss is
"^3.0.0 || ^4.0.0-beta.0", which excludes stable Tailwind v4 releases (e.g., v4.1.18 used elsewhere in the PR). Update to"^3.0.0 || ^4.0.0"to accept stable v4 versions.- "tailwindcss": "^3.0.0 || ^4.0.0-beta.0" + "tailwindcss": "^3.0.0 || ^4.0.0"
📜 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 (18)
examples/minimal-solidstart/package.json(1 hunks)packages/mime-types/package.json(7 hunks)packages/react/package.json(5 hunks)packages/react/src/styles.css(1 hunks)packages/react/tailwind.config.ts(0 hunks)packages/shared/package.json(2 hunks)packages/solid/postcss.config.cjs(0 hunks)packages/solid/src/styles.css(1 hunks)packages/solid/tailwind.config.cjs(0 hunks)packages/svelte/package.json(1 hunks)packages/svelte/postcss.config.cjs(0 hunks)packages/svelte/src/lib/styles.css(1 hunks)packages/svelte/tailwind.config.cjs(0 hunks)packages/svelte/tsconfig.json(1 hunks)packages/svelte/vite.config.ts(1 hunks)packages/uploadthing/package.json(12 hunks)packages/vue/package.json(2 hunks)packages/vue/src/styles.css(1 hunks)
💤 Files with no reviewable changes (5)
- packages/svelte/postcss.config.cjs
- packages/solid/tailwind.config.cjs
- packages/react/tailwind.config.ts
- packages/svelte/tailwind.config.cjs
- packages/solid/postcss.config.cjs
🚧 Files skipped from review as they are similar to previous changes (2)
- packages/svelte/package.json
- examples/minimal-solidstart/package.json
🧰 Additional context used
🧠 Learnings (4)
📚 Learning: 2024-11-11T19:59:56.512Z
Learnt from: markflorkowski
Repo: pingdotgg/uploadthing PR: 1046
File: playground-v6/app/layout.tsx:21-21
Timestamp: 2024-11-11T19:59:56.512Z
Learning: In the `playground-v6` project, using the Tailwind CSS CDN in `playground-v6/app/layout.tsx` is acceptable as it is a playground for testing purposes and not intended for production deployment.
Applied to files:
packages/vue/src/styles.csspackages/solid/src/styles.csspackages/react/src/styles.csspackages/svelte/src/lib/styles.csspackages/react/package.json
📚 Learning: 2024-11-05T17:11:33.300Z
Learnt from: juliusmarminge
Repo: pingdotgg/uploadthing PR: 1013
File: packages/mime-types/package.json:24-69
Timestamp: 2024-11-05T17:11:33.300Z
Learning: In this codebase, the bundler `bunchee` uses `package.json` as the source of truth for exports and outputs matching files during the build process. Therefore, the export paths specified in `package.json` align with the generated build output, even if the source files are located in a `src/` directory.
Applied to files:
packages/react/package.jsonpackages/vue/package.jsonpackages/mime-types/package.jsonpackages/uploadthing/package.jsonpackages/shared/package.json
📚 Learning: 2024-09-30T21:49:47.986Z
Learnt from: juliusmarminge
Repo: pingdotgg/uploadthing PR: 989
File: examples/minimal-tanstack-start/package.json:19-24
Timestamp: 2024-09-30T21:49:47.986Z
Learning: As of September 2024, TypeScript version 5.5.2 is available and valid.
Applied to files:
packages/mime-types/package.json
📚 Learning: 2024-11-07T18:28:14.191Z
Learnt from: juliusmarminge
Repo: pingdotgg/uploadthing PR: 1046
File: playground/package.json:26-26
Timestamp: 2024-11-07T18:28:14.191Z
Learning: In `package.json`, the `typescript-eslint` package is correctly used and should not be replaced with `typescript-eslint/eslint-plugin` and `typescript-eslint/parser` in modern configurations.
Applied to files:
packages/mime-types/package.jsonpackages/uploadthing/package.json
⏰ 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: bundle-analyze-result
- GitHub Check: build
- GitHub Check: e2e-node (backend-adapters)
🔇 Additional comments (14)
packages/svelte/tsconfig.json (1)
11-11: Verify implicitmoduleResolutiondefault behavior.Removing the explicit
"moduleResolution": "node"means TypeScript will now rely on its implicit default. With TypeScript 5.9.3, this defaults to"bundler"(whenmodule >= ES2015), which differs from the previous"node"strategy. While"bundler"is generally suitable for modern tooling, verify that:
- Module resolution continues to work correctly for all imports in the Svelte package
- No type resolution errors or unexpected import behavior surfaces in testing
- This change aligns with your modernization intent for the repo
If you prefer explicit configuration for maintainability and clarity, consider restoring the
"moduleResolution"setting. Given the TypeScript bump to 5.9.3, you may also want to explicitly set it to"bundler"to make the intent clear.packages/solid/src/styles.css (1)
1-3: Consider using Tailwind v4's simplified import syntax instead of selective layering.The current approach declares layers (
theme,base,components,utilities) but only importsthemeandutilities, leavingbaseandcomponentswithout content. According to Tailwind v4 documentation, the recommended migration is to use a single@import "tailwindcss";which automatically includes all layers.This selective approach may cause missing default HTML element styling (from the base layer) and unavailable component layers if your project uses custom utility components. Verify this is intentional, or simplify to the single import statement.
packages/vue/src/styles.css (1)
1-3: Verify: base and components layers declared but not imported.Like the solid styles file, this file declares base and components in the
@layerstatement but provides no content for them. This may result in missing default HTML element styling. Consider adopting Tailwind v4's recommended single import:@import "tailwindcss";.packages/svelte/src/lib/styles.css (1)
1-3: Verify: base and components layers declared but not imported.Consistent with other framework style files in the monorepo, this file declares four layers but only imports two (
themeandutilities). Thebaseandcomponentslayers are declared but empty, which may cause missing default styling. Verify this is intentional or migrate to Tailwind v4's recommended approach:@import "tailwindcss";.packages/react/src/styles.css (1)
1-3: Verify: incomplete layer migration across framework styles.All framework style files (React, Vue, Svelte, Solid) follow the same pattern of declaring four layers but only importing
themeandutilities. This leavesbaseandcomponentsempty. While this may be intentional, Tailwind v4 documentation recommends using a single@import "tailwindcss";which fully populates all layers. Confirm whether selective layering is intentional or if a full import is needed.packages/shared/package.json (2)
13-14: ESM module exports migration is consistent and correct.The transition from
.js/.d.tsto.mjs/.d.mts(for imports) and.d.cts(for requires) aligns with Tailwind v4 and modern TypeScript conventions. This provides proper ESM/CJS interoperability while maintaining the bunchee build assumption. No issues detected here.Also applies to: 19-20
54-54: Verify vitest 4.x compatibility (major version bump).This package bumps vitest from 3.2.4 to 4.0.15—a major version increase that may introduce breaking changes. Ensure the existing test suite passes with vitest 4. Similarly, @vitest/coverage-istanbul was bumped from 3.2.4 to 4.0.15 (also major version).
Also applies to: 60-60
packages/vue/package.json (1)
49-49: Tailwind CSS v4 major version bump requires careful validation.This package upgrades from Tailwind v3.4.16 to v4.1.18 (major version) and adds the new
@tailwindcss/cli. Per Tailwind v4 documentation, this introduces breaking changes including:
- Important modifier syntax:
text-2xl!(not!text-2xl)- Opacity utilities removed: use
bg-blue-500/50(notbg-blue-500 bg-opacity-20)- CSS variables: parentheses syntax
bg-(--var)(not bracketsbg-[--var])Verify that Vue components using Tailwind don't rely on removed utilities or deprecated syntax, and that the CSS layer migration aligns with v4 best practices.
Also applies to: 54-54
packages/uploadthing/package.json (2)
19-20: Large-scale ESM export migration is systematic and complete.All twelve public export paths (client, client-future, server, next, next-legacy, effect-platform, tw, fastify, express, h3, remix, types) were updated consistently from
.js/.d.tsto.mjs/.d.mts(import) while preserving.cjs/.d.cts(require). This is a well-executed module surface modernization with no gaps detected.Also applies to: 29-30, 39-40, 49-50, 59-60, 69-70, 80-81, 91-92, 101-102, 111-112, 121-122, 130-131
178-178: Verify vitest 4.x compatibility and MSW integration.Two major version bumps: vitest 3.2.4 → 4.0.15 and @vitest/coverage-istanbul 3.2.4 → 4.0.15. Additionally, MSW (Mock Service Worker) 2.12.4 is added, which may interact with vitest configuration. Ensure test suite and mocking setup remain compatible with vitest 4.
Also applies to: 191-191
packages/mime-types/package.json (2)
13-14: ESM export migration across all MIME type category exports is consistent.All six public export paths (root, ./application, ./audio, ./image, ./text, ./video) were updated systematically to use ESM module extensions (
.mjs/.d.mtsfor import,.cjs/.d.ctsfor require). No gaps or inconsistencies detected.Also applies to: 19-20, 29-30, 39-40, 49-50, 59-60, 69-70
98-99: Dependency updates are stable and conservative.Only minor/patch version updates to tsdown (0.14.1 → 0.17.3) and typescript (5.8.3 → 5.9.3). No major version bumps or new dependencies that could introduce risk. These are safe updates.
packages/react/package.json (2)
28-47: Subpath export updates look consistent—verifynative/+next-ssr-plugin/also emit dual ESM/CJS + dual d.ts flavors.
Same risk as root: consumer resolution will break if any ofindex.mjs,index.cjs,index.d.mts,index.d.cts(or the subpath equivalents) don’t exist after build/publish. Based on learnings, package.json drives build outputs, so this is likely intentional, but it’s still worth a quick artifact check. Based on learnings, bunchee usespackage.jsonas the output source of truth.
88-103: Fix vitest-browser-react version: 2.0.2 does not exist on npm.The package
[email protected]is unpublished; the latest stable release is 1.0.1 (with only 2.0.0 beta versions available). This will cause installation failures. Update to a valid version.The
vitestand@vitest/browserbumps to 4.0.15 (released Dec 2, 2025) are valid, and your existing browser config (playwright provider, chromium instance) is compatible.⛔ Skipped due to learnings
Learnt from: markflorkowski Repo: pingdotgg/uploadthing PR: 1138 File: playground/package.json:27-27 Timestamp: 2025-01-24T01:57:53.903Z Learning: When reviewing package versions, verify the latest version from the npm registry instead of making assumptions about version availability. Package versions can change frequently, and cached knowledge about versions can become outdated quickly.
There was a problem hiding this comment.
Actionable comments posted: 5
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (2)
playground/lib/actions.ts (1)
38-70: Add cache invalidation to server-side upload and delete actions.The
uploadFilesanddeleteFileactions don't invalidate the cached file list, causing stale data. The client uploader callsrouter.refresh()on success (line 70 of uploader.tsx), but the server uploader path has no equivalent cache refresh. Files uploaded via the server uploader or deleted viadeleteFilewon't appear/disappear in the file list until the page is manually refreshed.Update both actions to call
revalidatePath("/")or add auseEffectin the server uploader component to callrouter.refresh()after successful upload, matching the behavior of the client uploader.Also applies to: 88-102
packages/uploadthing/package.json (1)
200-200: Update tailwindcss peer dependency to allow stable v4 releases.The peer dependency currently restricts Tailwind CSS to
^3.0.0 || ^4.0.0-beta.0, but the devDependency uses^4.1.18(a stable release). Update the constraint to^3.0.0 || ^4.0.0to allow stable v4 without the beta restriction, since the library is already compatible with stable v4.
♻️ Duplicate comments (2)
packages/react/package.json (1)
67-67: Move build/test tools fromdependenciestodevDependencies.
@tailwindcss/cliand@vitest/browser-playwrightare development and testing tools with zero runtime usage. They should not be in production dependencies.
@tailwindcss/cliwas flagged in prior reviews but remains in dependencies. Move both entries todevDependenciesto avoid inflating consumer installations.Apply this diff to move these tools to devDependencies:
"dependencies": { - "@tailwindcss/cli": "^4.1.18", "@uploadthing/shared": "workspace:*", - "@vitest/browser-playwright": "^4.0.15", "file-selector": "0.6.0" }, "devDependencies": { + "@tailwindcss/cli": "^4.1.18", "@types/node": "^22.10.0", "@types/react": "19.2.7", "@types/react-dom": "19.2.3", + "@vitest/browser-playwright": "^4.0.15", ... }Also applies to: 69-69
playground-v6/lib/data.ts (1)
5-13: Same cache removal as inplayground/lib/data.ts.This file has identical changes to
playground/lib/data.ts. The same verification regarding cache invalidation behavior and UX impact applies here.
🧹 Nitpick comments (3)
playground/package.json (2)
14-14: Version pinning strategy is inconsistent across dependencies.Dependencies use a mix of exact pinning (effect, next, react, react-dom, typescript) and caret ranges (@tailwindcss/postcss, tailwindcss). This inconsistency could lead to unexpected minor/patch version differences between environments. Consider adopting a consistent strategy:
- Exact pinning for all (safer but requires manual updates)
- Caret ranges for all non-critical deps (more flexible)
Alternatively, document why certain packages use caret ranges if this is intentional.
Also applies to: 16-18, 24-24, 29-32
26-27: Type definitions version mismatch with runtime packages.
@types/reactis pinned to 19.2.7 whilereactis 19.2.3, and@types/react-domis 19.2.3 whilereact-domis 19.2.2. While minor mismatches are usually tolerable, consider aligning them to the same patch version for consistency (e.g., both 19.2.3).packages/uploadthing/vitest.config.ts (1)
11-15: Consider whether the outerbaseConfigmerge is necessary.
baseConfigis merged at three levels: the outer config (line 11) and within each project (lines 14-15, 25-26). In Vitest's project mode, each project config is independent, so the outer merge may be redundant if all relevant settings are already applied per-project.If the outer merge is intentional (e.g., for workspace-level plugins or resolve aliases), a brief comment would clarify the intent.
📜 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 (38)
docs/package.json(3 hunks)examples/backend-adapters/client-react/package.json(1 hunks)examples/minimal-appdir/package.json(2 hunks)examples/minimal-astro-react/package.json(1 hunks)examples/minimal-expo/package.json(3 hunks)examples/minimal-pagedir/package.json(1 hunks)examples/minimal-tanstack-start/package.json(1 hunks)examples/profile-picture/package.json(2 hunks)examples/with-clerk-appdir/package.json(2 hunks)examples/with-clerk-pagesdir/package.json(2 hunks)examples/with-clerk-react-router/package.json(2 hunks)examples/with-clerk-remix/package.json(1 hunks)examples/with-drizzle-appdir/package.json(2 hunks)examples/with-drizzle-pagesdir/package.json(2 hunks)examples/with-react-image-crop/package.json(2 hunks)examples/with-serveractions/package.json(1 hunks)examples/with-tailwindcss/package.json(1 hunks)packages/expo/package.json(1 hunks)packages/react/package.json(5 hunks)packages/react/vitest.config.ts(1 hunks)packages/shared/package.json(2 hunks)packages/shared/src/crypto.ts(1 hunks)packages/uploadthing/package.json(12 hunks)packages/uploadthing/vitest.config.ts(1 hunks)packages/vue/tailwind.config.ts(0 hunks)playground-v6/app/api/uploadthing/route.ts(0 hunks)playground-v6/lib/actions.ts(1 hunks)playground-v6/lib/const.ts(0 hunks)playground-v6/lib/data.ts(1 hunks)playground-v6/next.config.ts(0 hunks)playground-v6/package.json(2 hunks)playground/app/api/uploadthing/route.ts(0 hunks)playground/lib/actions.ts(1 hunks)playground/lib/const.ts(0 hunks)playground/lib/data.ts(1 hunks)playground/next.config.ts(0 hunks)playground/package.json(1 hunks)pnpm-workspace.yaml(1 hunks)
💤 Files with no reviewable changes (7)
- playground/next.config.ts
- playground-v6/next.config.ts
- playground-v6/lib/const.ts
- playground/lib/const.ts
- playground-v6/app/api/uploadthing/route.ts
- playground/app/api/uploadthing/route.ts
- packages/vue/tailwind.config.ts
🚧 Files skipped from review as they are similar to previous changes (13)
- examples/with-clerk-pagesdir/package.json
- playground-v6/package.json
- examples/with-drizzle-pagesdir/package.json
- examples/with-clerk-appdir/package.json
- examples/with-react-image-crop/package.json
- examples/with-drizzle-appdir/package.json
- examples/minimal-astro-react/package.json
- examples/with-tailwindcss/package.json
- examples/minimal-pagedir/package.json
- packages/expo/package.json
- examples/with-clerk-remix/package.json
- examples/with-clerk-react-router/package.json
- docs/package.json
🧰 Additional context used
🧠 Learnings (15)
📚 Learning: 2024-10-08T16:10:15.532Z
Learnt from: markflorkowski
Repo: pingdotgg/uploadthing PR: 978
File: examples/minimal-appdir/src/server/uploadthing.ts:62-62
Timestamp: 2024-10-08T16:10:15.532Z
Learning: In the `onUploadComplete` handler in `examples/minimal-appdir/src/server/uploadthing.ts`, the return value `{ foo: "bar" }` is intentionally a placeholder for user-defined logic and may represent database returns or other computed values.
Applied to files:
playground-v6/lib/actions.tsplayground/lib/actions.ts
📚 Learning: 2024-10-08T16:10:15.532Z
Learnt from: markflorkowski
Repo: pingdotgg/uploadthing PR: 978
File: examples/minimal-appdir/src/server/uploadthing.ts:41-43
Timestamp: 2024-10-08T16:10:15.532Z
Learning: In the `examples/minimal-appdir/src/server/uploadthing.ts` and other example files, the commented-out header validation code is intentional and serves as an example for users.
Applied to files:
playground-v6/lib/actions.tsplayground/lib/actions.ts
📚 Learning: 2024-11-21T23:47:38.115Z
Learnt from: markflorkowski
Repo: pingdotgg/uploadthing PR: 1061
File: docs/src/app/(docs)/file-routes/page.mdx:182-189
Timestamp: 2024-11-21T23:47:38.115Z
Learning: In `docs/src/app/(docs)/file-routes/page.mdx`, the Zod version requirement should remain as `>=3` and not be changed to `>=3.24`.
Applied to files:
examples/minimal-expo/package.json
📚 Learning: 2024-11-11T20:32:20.335Z
Learnt from: markflorkowski
Repo: pingdotgg/uploadthing PR: 1046
File: playground-v6/package.json:5-10
Timestamp: 2024-11-11T20:32:20.335Z
Learning: In the `playground-v6` project, the use of the experimental `--turbopack` flag is acceptable, and instability is expected.
Applied to files:
pnpm-workspace.yaml
📚 Learning: 2024-11-11T20:32:20.335Z
Learnt from: markflorkowski
Repo: pingdotgg/uploadthing PR: 1046
File: playground-v6/package.json:5-10
Timestamp: 2024-11-11T20:32:20.335Z
Learning: The `playground-v6` project is a testing playground and is not intended for production deployment, so a `start` script is unnecessary.
Applied to files:
pnpm-workspace.yaml
📚 Learning: 2024-11-11T20:32:20.334Z
Learnt from: markflorkowski
Repo: pingdotgg/uploadthing PR: 1046
File: playground-v6/package.json:5-10
Timestamp: 2024-11-11T20:32:20.334Z
Learning: In the `playground-v6` project, the `lint` script in `package.json` can be `"eslint"` without specifying the directory, as `eslint` defaults to `.`.
Applied to files:
pnpm-workspace.yaml
📚 Learning: 2024-11-11T20:10:04.389Z
Learnt from: markflorkowski
Repo: pingdotgg/uploadthing PR: 1046
File: playground-v6/components/uploader.tsx:19-21
Timestamp: 2024-11-11T20:10:04.389Z
Learning: In the 'playground' and 'playground-v6' directories, the code is intended for testing purposes and does not require additional complexity in error handling.
Applied to files:
pnpm-workspace.yaml
📚 Learning: 2024-11-11T19:59:56.512Z
Learnt from: markflorkowski
Repo: pingdotgg/uploadthing PR: 1046
File: playground-v6/app/layout.tsx:21-21
Timestamp: 2024-11-11T19:59:56.512Z
Learning: In the `playground-v6` project, using the Tailwind CSS CDN in `playground-v6/app/layout.tsx` is acceptable as it is a playground for testing purposes and not intended for production deployment.
Applied to files:
pnpm-workspace.yamlplayground-v6/lib/data.tsplayground/package.jsonpackages/react/package.json
📚 Learning: 2025-01-03T17:49:32.484Z
Learnt from: juliusmarminge
Repo: pingdotgg/uploadthing PR: 1099
File: packages/solid/src/utils/createFetch.ts:15-19
Timestamp: 2025-01-03T17:49:32.484Z
Learning: "createFetch" in packages/solid/src/utils/createFetch.ts is considered an internal function, so changes to its signature are not covered by semver guarantees.
Applied to files:
playground-v6/lib/data.tspackages/shared/src/crypto.tspackages/shared/package.json
📚 Learning: 2025-01-24T01:57:53.903Z
Learnt from: markflorkowski
Repo: pingdotgg/uploadthing PR: 1138
File: playground/package.json:27-27
Timestamp: 2025-01-24T01:57:53.903Z
Learning: When reviewing package versions, verify the latest version from the npm registry instead of making assumptions about version availability. Package versions can change frequently, and cached knowledge about versions can become outdated quickly.
Applied to files:
examples/profile-picture/package.json
📚 Learning: 2024-09-30T21:49:47.986Z
Learnt from: juliusmarminge
Repo: pingdotgg/uploadthing PR: 989
File: examples/minimal-tanstack-start/package.json:19-24
Timestamp: 2024-09-30T21:49:47.986Z
Learning: As of September 2024, TypeScript version 5.5.2 is available and valid.
Applied to files:
examples/minimal-appdir/package.json
📚 Learning: 2024-12-07T18:44:24.444Z
Learnt from: juliusmarminge
Repo: pingdotgg/uploadthing PR: 1090
File: docs/src/components/Code.tsx:135-137
Timestamp: 2024-12-07T18:44:24.444Z
Learning: In `docs/src/components/Code.tsx`, using type casts like `as any` is acceptable due to type mismatches between React 18 and 19. These casts will be addressed when the project upgrades to React 19.
Applied to files:
examples/minimal-appdir/package.json
📚 Learning: 2024-11-05T17:11:33.300Z
Learnt from: juliusmarminge
Repo: pingdotgg/uploadthing PR: 1013
File: packages/mime-types/package.json:24-69
Timestamp: 2024-11-05T17:11:33.300Z
Learning: In this codebase, the bundler `bunchee` uses `package.json` as the source of truth for exports and outputs matching files during the build process. Therefore, the export paths specified in `package.json` align with the generated build output, even if the source files are located in a `src/` directory.
Applied to files:
packages/shared/package.jsonpackages/react/package.jsonpackages/uploadthing/package.json
📚 Learning: 2024-10-09T22:39:50.896Z
Learnt from: riordanpawley
Repo: pingdotgg/uploadthing PR: 1005
File: packages/uploadthing/src/internal/upload.server.ts:35-35
Timestamp: 2024-10-09T22:39:50.896Z
Learning: In `packages/uploadthing/src/internal/upload.server.ts`, using `Effect.andThen(unsafeCoerce<unknown, UploadPutResult>)` when processing the JSON response is appropriate and should not be replaced with a type assertion.
Applied to files:
packages/uploadthing/package.json
📚 Learning: 2024-11-07T18:28:14.191Z
Learnt from: juliusmarminge
Repo: pingdotgg/uploadthing PR: 1046
File: playground/package.json:26-26
Timestamp: 2024-11-07T18:28:14.191Z
Learning: In `package.json`, the `typescript-eslint` package is correctly used and should not be replaced with `typescript-eslint/eslint-plugin` and `typescript-eslint/parser` in modern configurations.
Applied to files:
packages/uploadthing/package.json
⏰ 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)
- GitHub Check: bundle-analyze-result
- GitHub Check: e2e-node (backend-adapters)
- GitHub Check: build
- GitHub Check: build
🔇 Additional comments (23)
examples/backend-adapters/client-react/package.json (1)
19-21: Verify compatibility of major version upgrades (Vite 7, @vitejs/plugin-react-swc 4.x).This file includes two significant major version bumps:
@vitejs/plugin-react-swc: 3.7.2 → 4.2.2 (major version)vite: 6.3.4 → 7.2.7 (major version)These could introduce breaking changes. Ensure that the build pipeline, development server, and application runtime all work correctly with these versions.
Please verify the following:
- Run
npm installand confirm the dependency tree resolves without conflicts.- Run
npm run devandnpm run buildto ensure the Vite dev server and build complete successfully.- Test the application in the browser to confirm no runtime issues (especially with React 19 and SWC compilation).
- Check if there are any deprecation warnings or errors in the console during build or runtime.
You can also consult the latest documentation for these tools:
- Vite 7 release notes and migration guide
- @vitejs/plugin-react-swc changelog and breaking changes
playground/package.json (2)
1-34: Inconsistency between AI summary and provided code.The AI summary mentions updates to
engines(Node: >=22.x → ^24.10.0) andpackageManager([email protected] → [email protected]), but these fields are not present in the provided code. Verify whether these changes are in a separate section or if the summary is outdated.
14-14: Multiple major version upgrades require thorough testing of breaking changes.This PR upgrades three major frameworks with significant breaking changes:
- React 19.2.3: new use cache for instant navigation and ref callback changes
- Next.js 16.0.10: async params and searchParams becoming required, and middleware.ts being replaced by proxy.ts
- Tailwind CSS 4.1.18: opacity utilities removed (use
/syntax),!modifier moved after utility name, CSS variables use parenthesesEnsure the codebase has been updated to reflect these changes (e.g., if using middleware.ts, migrate to proxy.ts; if using opacity utilities like
bg-opacity-50, migrate tobg-blue-500/50; ensure ref callbacks don't return cleanup functions).Also applies to: 16-18, 24-24, 29-32
examples/minimal-tanstack-start/package.json (2)
23-23: Verify Vite 7.x compatibility with TanStack Router and Start.This upgrade is a major version bump (Vite 6.x → 7.x). Vite 7 may introduce breaking changes in config structure, plugin APIs, or dev/build behavior. Ensure that
@tanstack/react-routerand@tanstack/react-startare compatible with Vite 7, and test the build and dev workflows thoroughly.
The search results show historical issues with TanStack and Vite, but these are from earlier versions. I should check for more recent breaking changes in Vite 7 specifically.Good. The search shows that Vite 7 has breaking changes around Node.js requirements and some Sass/plugin APIs, but should be manageable. Now let me check TypeScript 5.9 for any breaking changes.Good information. TypeScript 5.9 has a potential breaking change around type inference leaks that could cause new type errors, but the major functionality is backward compatible.[scratchpad_end] -->
22-23: Verify TypeScript 5.9 type system changes against project codebase.TypeScript 5.9 may introduce changes in types and possibly new errors in some codebases due to fixes in type variable inference, which can often be fixed by adding type arguments to generic function calls. Run the TypeScript type checker after upgrading to ensure no new type errors arise.
packages/react/vitest.config.ts (1)
1-18: Clean migration to Vitest 4.x browser provider pattern.The update correctly:
- Uses
playwright()function call instead of the deprecated string-based provider- Applies
satisfies ViteUserConfigfor type safety without altering the inferred type- Maintains the existing test configuration structure
packages/uploadthing/vitest.config.ts (1)
11-42: Well-structured multi-project configuration.The separation of unit and browser test projects with explicit include/exclude patterns is clean and maintainable. The Vitest 4.x patterns are correctly applied.
packages/shared/package.json (2)
43-62: Dependency updates look appropriate.All changes maintain proper separation between runtime dependencies (effect) and dev-only tools. The version bumps are consistent with the repo-wide maintenance effort.
13-20: No issues found—export declarations are correctly configured.The tsdown configuration with
format: ["esm", "cjs"]properly generates all four declared file variants (.mjs,.cjs,.d.mts,.d.cts). This pattern is consistent with other packages in the repository (react, mime-types, uploadthing, vue) and aligns with tsdown's dual-format type generation for ESM and CJS modules.packages/react/package.json (3)
72-76: Peer dependency updates align with React 19 support.The
reactpeer dependency updated to^19.2.3is consistent with the repo-wide React 19 upgrade effort mentioned in the PR objectives.
82-105: DevDependencies section looks good.All entries are appropriately scoped to development/build time (vitest, tailwindcss, tsdown, testing utilities). Once the build tools are moved from dependencies (as noted in the prior comment), this section will be complete.
13-47: All declared export entry points have matching tsdown configuration.The tsdown configuration correctly declares three entry points (
dist/index,native/index,next-ssr-plugin/index) matching the exports inpackage.json, withformat: ["esm", "cjs"]anddtsenabled. This ensures all type variants (.d.mtsand.d.cts) and output formats (.mjsand.cjs) will be generated as declared.examples/with-serveractions/package.json (1)
17-22: TypeScript bump to 5.9.3 is compatible with Next.js 15.5.8. Next.js 15+ officially supports TypeScript 5.x, and TypeScript 5.9.3 is a stable patch release with no documented user-facing breaking changes. Run the example's CI/typecheck to confirm the build succeeds as standard practice.playground/lib/data.ts (1)
5-13: Verify intentional removal of cache tagging and potential UX impact.The removal of
unstable_cacheTagand the cache directive means file listings are no longer explicitly cached or invalidated. In Next.js 15+, GET route handlers default to uncached, which may align with this change. However, verify that users will see fresh data after upload/delete operations without manual page refresh.Consider testing the following scenario:
- Load the file list
- Upload a new file
- Check if the file list automatically reflects the new upload
If stale data persists, you may need to either:
- Add explicit cache revalidation using
revalidatePath()- Implement client-side refetching after mutations
- Document the expected behavior if manual refresh is required
playground-v6/lib/actions.ts (1)
38-70: Consider adding cache revalidation or client-side refetch after file mutations.Both
uploadFilesanddeleteFileserver actions complete without invalidating any caches—there are norevalidateTag(),revalidatePath(), orrouter.refresh()calls. Users may see stale file lists until the cache naturally expires or they manually refresh.This is acceptable for a Next.js 15+ playground example relying on framework-level caching defaults, but for production code, consider either server-side revalidation (e.g.,
revalidatePath('/files')) or client-side refetching to ensure the UI reflects mutations immediately.playground/lib/actions.ts (1)
9-9: LGTM - Import cleaned up correctly.The import now only includes
SESSION_COOKIE_NAME, consistent with the removal ofCACHE_TAGSfrom the constants module.examples/minimal-appdir/package.json (1)
23-23: TypeScript 5.9.3 is stable and compatible with Next.js 15.5.8, but verify no breaking changes impact this example.TypeScript 5.9.3 is a released, stable version with no known security issues. Next.js 15.5.8 supports TypeScript 5.9 without compatibility concerns. However, TypeScript 5.9 introduced breaking changes in ArrayBuffer/typed-array typing, type argument inference, and DOM API definitions (lib.d.ts) that could surface new type errors. Verify the example builds cleanly and test that existing type checks still pass after this upgrade.
examples/minimal-expo/package.json (1)
51-51: Tailwind CSS v4 is already properly configured in this example.The codebase uses only v4-compatible Tailwind patterns (standard
opacity-*utilities, no deprecated*-opacity-*modifiers, no old-style important syntax). No migration work is needed. The caret version constraint (^4.1.18) is appropriate for v4.x releases, as breaking changes only occur with major version bumps.packages/shared/src/crypto.ts (1)
82-89: Theas anycast may be unavoidable; verify ifas BufferSourcewould resolve the type error.While using a more specific cast like
as BufferSourceis generally preferable toas any, the fact that the code usesas anysuggests that more specific type casts may not satisfy TypeScript either.
Encoding.decodeHexreturnsEither<Uint8Array, DecodeException>, and after unwrapping withyield*,sigBytesshould beUint8Array. SinceUint8Arrayis a validArrayBufferView(part ofBufferSource), the type mismatch likely stems from type definition misalignment in the Effect library or crypto API types rather than an actual incompatibility.Before suggesting
as BufferSource, confirm whether it resolves the TypeScript error. If it doesn't, the currentas anyworkaround may be the only viable option until type definitions align in future Effect library versions.pnpm-workspace.yaml (1)
7-8: vite 7.2.7 is valid and recently released (Dec 8, 2025).The workspace-level override to 7.2.7 is a recent, stable release available on npm. Ensure all workspace packages, particularly playground-v6 with experimental features like
--turbopack, are tested against this version for compatibility.examples/profile-picture/package.json (1)
36-36: All package versions are valid; Tailwind v4 syntax is correctly implemented.The upgrade to Tailwind CSS v4.1.18 is confirmed valid, and the codebase already uses v4-compliant syntax:
- Opacity modifiers used correctly (e.g.,
hover:opacity-75,disabled:opacity-50,bg-primary/90)- No old v3 syntax patterns (
opacity-*utilities,!prefixmodifiers,[--var]brackets) detected- CSS theme variables in
globals.cssproperly defined using standard CSS custom propertiesAll dependency versions verified from npm registry:
- tailwindcss 4.1.18 ✓
- @tailwindcss/postcss 4.1.18 ✓
- typescript 5.9.3 ✓
- typescript-eslint 8.49.0 ✓
- eslint 9.25.1 ✓
packages/uploadthing/package.json (2)
15-133: Verify that tsdown generates the declared .mjs and .d.mts file extensions.All export paths have been switched from
.js/.d.tsto.mjs/.d.mtsfor ESM imports. Per the codebase learnings,buncheeuses package.json exports as the source of truth and generates output files matching the declared paths. Confirm thattsdown(the bundler used here) follows the same pattern and actually outputs files with these extensions.Additionally, the
./typesexport (line 130–131) now declares only ES module paths with no CommonJS require fallback, which is a potential breaking change if any consumers userequire("uploadthing/types"). Verify whether this intentional or an oversight.Run the following script to verify the build output includes the declared file extensions:
#!/bin/bash # Description: Verify that tsdown generates .mjs and .d.mts files matching package.json exports # Build the package cd packages/uploadthing npm run build 2>&1 # List generated files in export directories echo "=== Checking for generated .mjs files ===" find client client-future server next next-legacy effect-platform tw fastify express h3 remix types \ -name "*.mjs" -o -name "*.d.mts" 2>/dev/null | head -20 echo "" echo "=== Checking for .js/.d.ts files (old format) ===" find client client-future server next next-legacy effect-platform tw fastify express h3 remix types \ -name "*.js" -o -name "*.d.ts" 2>/dev/null | head -20 echo "" echo "=== tsdown config check ===" # Look for tsdown configuration in package.json or tsconfig cat tsconfig.json 2>/dev/null | grep -A 10 "compilerOptions" || echo "tsconfig.json not found in package root"
162-195: Major version upgrades are properly integrated and tested.The significant version bumps—express
^5.0.1, fastify^5.2.0, tailwindcss^4.1.18, vitest4.0.15, msw2.12.4, and body-parser^2.2.1—are confirmed working through comprehensive adapter tests intest/node/adapters.test.ts. The express and fastify adapters use standard APIs compatible with v5.x, tailwindcss v4 is explicitly supported viasrc/tw/v4.cssand peerDependencies allowing both v3 and v4, and tests confirm integration with current vitest and msw versions.
There was a problem hiding this comment.
Actionable comments posted: 1
♻️ Duplicate comments (1)
examples/with-clerk-react-router/vite.config.ts (1)
1-14: Vite config update looks right; verify plugin compatibility/ordering for Vite 7 + Tailwind v4.
projects: ["./tsconfig.json"]is a good hardening to avoid multi-project surprises.Also make sure the example’s CSS entry has been migrated to Tailwind v4’s
@import "tailwindcss";style (since you’re now ontailwindcss@^4.1.18).
🧹 Nitpick comments (1)
examples/with-clerk-react-router/app/routes/api.uploadthing.ts (1)
35-36: Exports maintain the same public API.The
loaderandactionexports are correctly delegated from the handler object. The public API surface remains unchanged.Note: The playground example (
playground/app/api/uploadthing/route.ts) uses direct destructuring (export const { GET, POST } = createRouteHandler(...)), while this file now uses an intermediate variable. Both patterns work fine; just noting the stylistic difference.
📜 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 (25)
examples/with-clerk-react-router/app/entry.client.tsx(0 hunks)examples/with-clerk-react-router/app/entry.server.tsx(0 hunks)examples/with-clerk-react-router/app/routes/api.uploadthing.ts(1 hunks)examples/with-clerk-react-router/app/tailwind.css(1 hunks)examples/with-clerk-react-router/package.json(1 hunks)examples/with-clerk-react-router/postcss.config.js(0 hunks)examples/with-clerk-react-router/react-router.config.ts(1 hunks)examples/with-clerk-react-router/tailwind.config.ts(0 hunks)examples/with-clerk-react-router/tsconfig.json(1 hunks)examples/with-clerk-react-router/vite.config.ts(1 hunks)examples/with-clerk-remix/.env.example(0 hunks)examples/with-clerk-remix/README.md(0 hunks)examples/with-clerk-remix/app/entry.client.tsx(0 hunks)examples/with-clerk-remix/app/entry.server.tsx(0 hunks)examples/with-clerk-remix/app/root.tsx(0 hunks)examples/with-clerk-remix/app/routes/_index.tsx(0 hunks)examples/with-clerk-remix/app/routes/api.uploadthing.tsx(0 hunks)examples/with-clerk-remix/app/tailwind.css(0 hunks)examples/with-clerk-remix/app/utils/uploadthing.ts(0 hunks)examples/with-clerk-remix/package.json(0 hunks)examples/with-clerk-remix/postcss.config.js(0 hunks)examples/with-clerk-remix/tailwind.config.ts(0 hunks)examples/with-clerk-remix/tsconfig.json(0 hunks)examples/with-clerk-remix/vite.config.ts(0 hunks)playground/app/api/uploadthing/route.ts(0 hunks)
💤 Files with no reviewable changes (19)
- examples/with-clerk-remix/.env.example
- examples/with-clerk-react-router/postcss.config.js
- examples/with-clerk-remix/app/routes/api.uploadthing.tsx
- examples/with-clerk-remix/tsconfig.json
- examples/with-clerk-remix/app/routes/_index.tsx
- examples/with-clerk-remix/postcss.config.js
- examples/with-clerk-remix/README.md
- examples/with-clerk-remix/app/utils/uploadthing.ts
- examples/with-clerk-react-router/tailwind.config.ts
- examples/with-clerk-remix/vite.config.ts
- examples/with-clerk-react-router/app/entry.client.tsx
- examples/with-clerk-remix/app/tailwind.css
- examples/with-clerk-remix/package.json
- examples/with-clerk-remix/app/entry.server.tsx
- playground/app/api/uploadthing/route.ts
- examples/with-clerk-remix/tailwind.config.ts
- examples/with-clerk-react-router/app/entry.server.tsx
- examples/with-clerk-remix/app/entry.client.tsx
- examples/with-clerk-remix/app/root.tsx
🧰 Additional context used
🧠 Learnings (2)
📚 Learning: 2024-11-11T19:59:56.512Z
Learnt from: markflorkowski
Repo: pingdotgg/uploadthing PR: 1046
File: playground-v6/app/layout.tsx:21-21
Timestamp: 2024-11-11T19:59:56.512Z
Learning: In the `playground-v6` project, using the Tailwind CSS CDN in `playground-v6/app/layout.tsx` is acceptable as it is a playground for testing purposes and not intended for production deployment.
Applied to files:
examples/with-clerk-react-router/app/tailwind.cssexamples/with-clerk-react-router/package.json
📚 Learning: 2024-10-08T16:10:15.532Z
Learnt from: juliusmarminge
Repo: pingdotgg/uploadthing PR: 980
File: packages/solid/src/create-uploadthing.ts:119-119
Timestamp: 2024-10-08T16:10:15.532Z
Learning: In this codebase, the naming conventions differ between frameworks to align with ecosystem practices:
- In React and Vue, functions are prefixed with `useX` (e.g., `useRouteConfig`) to match built-in hooks and conventions.
- In Solid and Svelte, functions are prefixed with `createX` (e.g., `createRouteConfig`) to align with their respective built-in functions and ecosystem conventions.
Applied to files:
examples/with-clerk-react-router/vite.config.tsexamples/with-clerk-react-router/app/routes/api.uploadthing.tsexamples/with-clerk-react-router/react-router.config.ts
🧬 Code graph analysis (1)
examples/with-clerk-react-router/app/routes/api.uploadthing.ts (1)
playground/app/api/uploadthing/route.ts (2)
createRouteHandler(89-92)uploadRouter(15-85)
⏰ 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)
- GitHub Check: bundle-analyze-result
- GitHub Check: lint
- GitHub Check: e2e-node (backend-adapters)
- GitHub Check: build
🔇 Additional comments (5)
examples/with-clerk-react-router/app/tailwind.css (2)
1-1: Migrate to Tailwind CSS v4 import syntax.The change from
@tailwinddirectives to@import "tailwindcss"aligns correctly with Tailwind CSS v4. Per the library documentation, v4 introduces a new import style that consolidates the three separate directives into a single import statement.
1-23: Inconsistency between AI summary and actual code state.The AI summary claims that the
-webkit-font-smoothingand-moz-osx-font-smoothingproperties were removed from:root, but lines 14–15 still contain these properties in the final code (with no~change markers). Please clarify whether these properties were intentionally retained or if they should have been removed as part of this PR.examples/with-clerk-react-router/app/routes/api.uploadthing.ts (1)
33-34: LGTM! Refactored to explicit handler object.The change from direct destructuring to an intermediate
handlervariable is functionally equivalent and may improve debuggability by making the handler object explicit.examples/with-clerk-react-router/tsconfig.json (1)
2-12: Good: explicitnode_modulesexclusion matches the broadincludeglobs.examples/with-clerk-react-router/react-router.config.ts (1)
1-7: Config looks good;ssr: trueis correct for @react-router/dev v7.x.
Thessroption is the intended flag to enable server-side rendering (default behavior). Nice use ofsatisfies Configto maintain type safety without widening the export type.
There was a problem hiding this comment.
Actionable comments posted: 4
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
packages/react/package.json (1)
59-62: Addtanstack-ssr-pluginto thefilesarray.The new
tanstack-ssr-pluginexport block (lines 48-57) references files in atanstack-ssr-plugin/directory, but this directory is not included in thefilesarray for npm publication. This will cause the published package to be missing the tanstack-ssr-plugin files, breaking imports.Apply this diff to include the new directory:
"files": [ "dist", "native", - "next-ssr-plugin" + "next-ssr-plugin", + "tanstack-ssr-plugin" ],
♻️ Duplicate comments (2)
packages/react/tsdown.config.ts (1)
30-32: CSS minification detection is broken (duplicate concern).As previously noted, the dev-mode detection logic (
opts.clean.length === 0) no longer works withclean: falseon line 20. Theopts.cleanproperty will always be empty, makingisDevalwaystrueand preventing CSS minification in production builds.packages/react/package.json (1)
77-77: Move@tailwindcss/clitodevDependencies(duplicate concern).As noted in previous reviews,
@tailwindcss/cliis a build-time tool and should not be in runtimedependencies. This inflates consumer installs unnecessarily.
🧹 Nitpick comments (1)
packages/react/src/tanstack-ssr-plugin.ts (1)
35-58: Consider adding error handling for server-side config extraction.The SSR integration logic is sound and correctly wraps
hydrate/dehydrateto inject and restore UploadThing config across the server/client boundary. However, there's no error handling ifgetUtConfig()fails or returns invalid data. While this might be acceptable for an integration utility that assumes valid inputs, consider adding validation.Apply this diff to add basic error handling:
if (router.isServer) { router.options.dehydrate = async () => { const ogDehydrated = (await ogDehydrate?.()) as DehydratedState; const utConfig = getUtConfig(); + if (!utConfig) { + console.warn('[UploadThing SSR] No config returned from getUtConfig'); + } globalThis.__UPLOADTHING = utConfig; return { ...ogDehydrated, uploadthingConfig: utConfig, }; }; } else { router.options.hydrate = async (dehydrated: DehydratedState) => { await ogHydrate?.(dehydrated); + if (!dehydrated.uploadthingConfig) { + console.warn('[UploadThing SSR] No uploadthingConfig found in dehydrated state'); + } globalThis.__UPLOADTHING = dehydrated.uploadthingConfig; }; }
📜 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 (27)
.changeset/friendly-poets-scream.md(1 hunks).changeset/pink-rabbits-shave.md(1 hunks)docs/package.json(3 hunks)examples/backend-adapters/client-react/package.json(1 hunks)examples/minimal-appdir/package.json(1 hunks)examples/minimal-astro-react/package.json(1 hunks)examples/minimal-expo/package.json(3 hunks)examples/minimal-pagedir/package.json(1 hunks)examples/minimal-tanstack-start/package.json(1 hunks)examples/minimal-tanstack-start/src/routeTree.gen.ts(2 hunks)examples/minimal-tanstack-start/src/router.tsx(1 hunks)examples/minimal-tanstack-start/src/routes/api.uploadthing.ts(1 hunks)examples/minimal-tanstack-start/vite.config.ts(1 hunks)examples/profile-picture/package.json(2 hunks)examples/with-clerk-appdir/package.json(2 hunks)examples/with-clerk-pagesdir/package.json(2 hunks)examples/with-clerk-react-router/package.json(1 hunks)examples/with-drizzle-appdir/package.json(2 hunks)examples/with-drizzle-pagesdir/package.json(2 hunks)examples/with-react-image-crop/package.json(1 hunks)examples/with-serveractions/package.json(1 hunks)examples/with-tailwindcss/package.json(1 hunks)packages/react/package.json(4 hunks)packages/react/src/tanstack-ssr-plugin.ts(1 hunks)packages/react/tsdown.config.ts(1 hunks)playground/package.json(1 hunks)pnpm-workspace.yaml(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (12)
- examples/backend-adapters/client-react/package.json
- examples/profile-picture/package.json
- examples/with-tailwindcss/package.json
- examples/minimal-expo/package.json
- examples/with-clerk-appdir/package.json
- examples/with-drizzle-pagesdir/package.json
- docs/package.json
- examples/minimal-appdir/package.json
- pnpm-workspace.yaml
- examples/with-clerk-pagesdir/package.json
- examples/with-drizzle-appdir/package.json
- examples/minimal-astro-react/package.json
🧰 Additional context used
🧠 Learnings (9)
📓 Common learnings
Learnt from: markflorkowski
Repo: pingdotgg/uploadthing PR: 1046
File: playground-v6/package.json:5-10
Timestamp: 2024-11-11T20:32:20.334Z
Learning: In the `playground-v6` project, the `lint` script in `package.json` can be `"eslint"` without specifying the directory, as `eslint` defaults to `.`.
Learnt from: markflorkowski
Repo: pingdotgg/uploadthing PR: 1138
File: playground/package.json:27-27
Timestamp: 2025-01-24T01:57:53.903Z
Learning: When reviewing package versions, verify the latest version from the npm registry instead of making assumptions about version availability. Package versions can change frequently, and cached knowledge about versions can become outdated quickly.
Learnt from: markflorkowski
Repo: pingdotgg/uploadthing PR: 1046
File: playground-v6/package.json:5-10
Timestamp: 2024-11-11T20:32:20.335Z
Learning: The `playground-v6` project is a testing playground and is not intended for production deployment, so a `start` script is unnecessary.
Learnt from: juliusmarminge
Repo: pingdotgg/uploadthing PR: 1013
File: packages/mime-types/package.json:24-69
Timestamp: 2024-11-05T17:11:33.300Z
Learning: In this codebase, the bundler `bunchee` uses `package.json` as the source of truth for exports and outputs matching files during the build process. Therefore, the export paths specified in `package.json` align with the generated build output, even if the source files are located in a `src/` directory.
📚 Learning: 2024-10-08T16:10:15.532Z
Learnt from: juliusmarminge
Repo: pingdotgg/uploadthing PR: 980
File: packages/solid/src/create-uploadthing.ts:119-119
Timestamp: 2024-10-08T16:10:15.532Z
Learning: In this codebase, the naming conventions differ between frameworks to align with ecosystem practices:
- In React and Vue, functions are prefixed with `useX` (e.g., `useRouteConfig`) to match built-in hooks and conventions.
- In Solid and Svelte, functions are prefixed with `createX` (e.g., `createRouteConfig`) to align with their respective built-in functions and ecosystem conventions.
Applied to files:
examples/minimal-tanstack-start/src/router.tsxexamples/minimal-tanstack-start/src/routes/api.uploadthing.tsexamples/minimal-tanstack-start/src/routeTree.gen.ts
📚 Learning: 2024-12-07T18:44:24.444Z
Learnt from: juliusmarminge
Repo: pingdotgg/uploadthing PR: 1090
File: docs/src/components/Code.tsx:135-137
Timestamp: 2024-12-07T18:44:24.444Z
Learning: In `docs/src/components/Code.tsx`, using type casts like `as any` is acceptable due to type mismatches between React 18 and 19. These casts will be addressed when the project upgrades to React 19.
Applied to files:
examples/with-serveractions/package.jsonexamples/minimal-tanstack-start/package.jsonexamples/minimal-pagedir/package.jsonexamples/with-clerk-react-router/package.json
📚 Learning: 2025-01-24T01:57:53.903Z
Learnt from: markflorkowski
Repo: pingdotgg/uploadthing PR: 1138
File: playground/package.json:27-27
Timestamp: 2025-01-24T01:57:53.903Z
Learning: When reviewing package versions, verify the latest version from the npm registry instead of making assumptions about version availability. Package versions can change frequently, and cached knowledge about versions can become outdated quickly.
Applied to files:
examples/with-serveractions/package.jsonexamples/minimal-pagedir/package.jsonexamples/with-clerk-react-router/package.json
📚 Learning: 2024-10-08T16:10:15.532Z
Learnt from: markflorkowski
Repo: pingdotgg/uploadthing PR: 978
File: examples/minimal-appdir/src/server/uploadthing.ts:62-62
Timestamp: 2024-10-08T16:10:15.532Z
Learning: In the `onUploadComplete` handler in `examples/minimal-appdir/src/server/uploadthing.ts`, the return value `{ foo: "bar" }` is intentionally a placeholder for user-defined logic and may represent database returns or other computed values.
Applied to files:
examples/minimal-tanstack-start/src/routes/api.uploadthing.ts
📚 Learning: 2024-10-08T16:10:15.532Z
Learnt from: markflorkowski
Repo: pingdotgg/uploadthing PR: 978
File: examples/minimal-appdir/src/server/uploadthing.ts:41-43
Timestamp: 2024-10-08T16:10:15.532Z
Learning: In the `examples/minimal-appdir/src/server/uploadthing.ts` and other example files, the commented-out header validation code is intentional and serves as an example for users.
Applied to files:
examples/minimal-tanstack-start/src/routes/api.uploadthing.ts
📚 Learning: 2024-11-07T18:10:26.762Z
Learnt from: juliusmarminge
Repo: pingdotgg/uploadthing PR: 1046
File: playground/app/layout.tsx:0-0
Timestamp: 2024-11-07T18:10:26.762Z
Learning: In Next.js, components in the `/app` directory are server components by default unless specified otherwise.
Applied to files:
examples/minimal-tanstack-start/src/routes/api.uploadthing.tsexamples/minimal-tanstack-start/src/routeTree.gen.ts
📚 Learning: 2024-11-05T17:11:33.300Z
Learnt from: juliusmarminge
Repo: pingdotgg/uploadthing PR: 1013
File: packages/mime-types/package.json:24-69
Timestamp: 2024-11-05T17:11:33.300Z
Learning: In this codebase, the bundler `bunchee` uses `package.json` as the source of truth for exports and outputs matching files during the build process. Therefore, the export paths specified in `package.json` align with the generated build output, even if the source files are located in a `src/` directory.
Applied to files:
packages/react/tsdown.config.tspackages/react/package.json
📚 Learning: 2024-11-11T19:59:56.512Z
Learnt from: markflorkowski
Repo: pingdotgg/uploadthing PR: 1046
File: playground-v6/app/layout.tsx:21-21
Timestamp: 2024-11-11T19:59:56.512Z
Learning: In the `playground-v6` project, using the Tailwind CSS CDN in `playground-v6/app/layout.tsx` is acceptable as it is a playground for testing purposes and not intended for production deployment.
Applied to files:
examples/with-clerk-react-router/package.jsonpackages/react/package.json
🧬 Code graph analysis (2)
examples/minimal-tanstack-start/src/router.tsx (2)
examples/minimal-tanstack-start/src/server/uploadthing.ts (1)
uploadRouter(21-49)packages/react/src/tanstack-ssr-plugin.ts (1)
setupRouterSsrUploadThingIntegration(35-58)
examples/minimal-tanstack-start/src/routeTree.gen.ts (1)
examples/minimal-tanstack-start/src/router.tsx (1)
getRouter(14-23)
🪛 Biome (2.1.2)
packages/react/src/tanstack-ssr-plugin.ts
[error] 27-27: Do not shadow the global "globalThis" property.
Consider renaming this variable. It's easy to confuse the origin of variables when they're named after a known global.
(lint/suspicious/noShadowRestrictedNames)
🪛 GitHub Actions: CI
examples/minimal-tanstack-start/src/router.tsx
[error] 4-4: Cannot find module '@uploadthing/react/tanstack-ssr-plugin' or its corresponding type declarations.
🔇 Additional comments (20)
.changeset/pink-rabbits-shave.md (1)
1-5: Changeset is properly formatted and version bump is appropriate.The minor version bump aligns with the introduction of a new react-router adapter feature, and the changeset follows the standard format used by the changesets tool. The feature description is clear and matches the intended changes.
examples/with-clerk-react-router/package.json (3)
18-19: ✅ React and React-DOM versions now aligned.Both
reactandreact-domare pinned to exact version19.2.3, following React's versioning policy that requires patch-level alignment to prevent runtime errors and renderer incompatibilities. The previous mismatch (19.2.3 vs 19.2.2) has been resolved.
26-26: Tailwind v4 setup in package.json is correct; verify source file migration.The addition of
@tailwindcss/vite@^4.1.18and upgrade totailwindcss@^4.1.18are appropriate for a Vite-based project. The removal ofpostcssfrom devDependencies makes sense, as@tailwindcss/vitebundles PostCSS internally. However, this package.json change must be paired with updates to source files—specifically,app/tailwind.cssshould replace the deprecated v3@tailwinddirectives with@import "tailwindcss";, andpostcss.config.jsshould be removed or updated if it still exists.Please verify that:
app/tailwind.csshas been migrated from@tailwind base; @tailwind components; @tailwind utilities;to@import "tailwindcss";postcss.config.jshas been removed or is no longer referenced- The Vite config properly integrates the
@tailwindcss/vitepluginYou can confirm this by running a build (
react-router build) and checking that Tailwind CSS loads without errors.Also applies to: 29-29
13-15: React Router ecosystem versions are consistent and compatible.All React Router packages (
@react-router/node,@react-router/serve,react-router,react-router-dom,@react-router/dev) are upgraded to7.10.1, which is compatible with React 19.2.3. Additionally,@clerk/[email protected]supports React 18+ without known conflicts. No peer-dependency issues are anticipated.Also applies to: 20-21, 25-25
examples/with-serveractions/package.json (3)
12-14: React and Next.js versions are now correctly aligned with critical security fixes.Next.js 16 uses the latest React Canary release, which includes React 19.2 features. React versions 19.0.0 through 19.2.2 are vulnerable to critical RSC bugs (CVE-2025-55182, CVE-2025-55184, CVE-2025-55183); version 19.2.3 contains the necessary security patches. Both
reactandreact-domare now perfectly aligned at 19.2.3.
18-20: Type definitions are correctly aligned with installed React versions.Next.js 16 upgrade guidance recommends upgrading
@types/reactand@types/react-domto their latest versions. The@types/react-dom(19.2.3) is perfectly aligned withreact-dom(19.2.3), and@types/react(19.2.7) is the latest available version, which is appropriate forreact(19.2.3).
21-21: Tooling versions support the upgraded framework stack.TypeScript 5.9.3 meets Next.js 16's minimum requirement and aligns with the latest ecosystem. Combined with the Node.js and pnpm engine constraints (per ai_summary), the tooling versions are modern and sustainable.
examples/with-react-image-crop/package.json (3)
14-15: React and React-DOM patch update is safe.The update from React 19.2.2 to 19.2.3 is a patch release and should be backward-compatible. No action required.
23-23: TypeScript minor version update is safe.The update from TypeScript 5.8.3 to 5.9.3 is a standard minor version bump. No breaking changes expected.
16-16: Clarify react-image-crop status.The AI summary claims react-image-crop was "added" as a new dependency, but line 16 is not marked as a changed line in the diff. Please confirm whether this dependency was previously missing from the file or if the summary is inaccurate.
examples/minimal-pagedir/package.json (2)
14-15: ✅ React/React-DOM version mismatch resolved.The version alignment (both at 19.2.3) resolves the prior critical pipeline failure. This looks good.
13-13: Next.js 16.0.10 upgrade is compatible with this minimal example.Next.js 16 introduces significant breaking changes (async-only cookies/headers APIs, middleware→proxy transition, Turbopack changes), but this minimal-pagedir example uses a simple Pages Router with no experimental features, no middleware, no dynamic APIs, and no deprecated configurations. The dependencies (React 19.2.3, TypeScript 5.9.3, Node types ^22.10.0) already meet Next.js 16 requirements. No code changes are needed for this upgrade.
playground/package.json (3)
16-16: Confirm Next.js 16.0.10 + React 19.2.3 compatibility and breaking changes addressed.Next.js 16 uses the latest React Canary release, which includes React 19.2 features. Verify your codebase has addressed Next.js 16 breaking changes:
- Turbopack is now the default bundler (no longer need
--turbopackflag in dev script)- Async params changes (if using dynamic routes)
- next/image defaults may have changed
- Separate output directories for dev/build (
.next/devvs.next/build)The versions are compatible, but confirm your code follows Next.js 16 patterns.
24-24: Verify @tailwindcss/postcss integration and PostCSS configuration.The addition of @tailwindcss/postcss ^4.1.18 and postcss 8.5.6 are required for Tailwind v4, with the engine requiring Node.js 20+. Ensure your
postcss.config.jsor equivalent is properly configured to use the new PostCSS plugin.Also applies to: 30-30
14-18: Update Tailwind CSS utility syntax in appearance prop from v3 to v4 format.The
appearanceprop inplayground/components/uploader.tsx(lines 78-79) uses old Tailwind v3 syntax for the important modifier. In Tailwind v4, the!modifier must be placed at the end of the utility, not the beginning.Changes needed:
"!text-sm/6"→"text-sm/6!""!h-0"→"h-0!"The rest of the Tailwind v4 migration is complete: global CSS correctly uses
@import "tailwindcss", CSS variables are properly configured, and postcss setup is correct.⛔ Skipped due to learnings
Learnt from: markflorkowski Repo: pingdotgg/uploadthing PR: 1046 File: playground-v6/app/layout.tsx:21-21 Timestamp: 2024-11-11T19:59:56.512Z Learning: In the `playground-v6` project, using the Tailwind CSS CDN in `playground-v6/app/layout.tsx` is acceptable as it is a playground for testing purposes and not intended for production deployment.Learnt from: markflorkowski Repo: pingdotgg/uploadthing PR: 1138 File: playground/package.json:27-27 Timestamp: 2025-01-24T01:57:53.903Z Learning: When reviewing package versions, verify the latest version from the npm registry instead of making assumptions about version availability. Package versions can change frequently, and cached knowledge about versions can become outdated quickly.Learnt from: juliusmarminge Repo: pingdotgg/uploadthing PR: 1090 File: docs/src/components/Code.tsx:135-137 Timestamp: 2024-12-07T18:44:24.444Z Learning: In `docs/src/components/Code.tsx`, using type casts like `as any` is acceptable due to type mismatches between React 18 and 19. These casts will be addressed when the project upgrades to React 19..changeset/friendly-poets-scream.md (1)
1-5: LGTM! Changeset properly declares the TanStack Start SSR integration feature.The changeset correctly declares a minor version bump for
@uploadthing/reactand clearly describes the new feature.packages/react/src/tanstack-ssr-plugin.ts (1)
27-29: Static analysis false positive—ignore the Biome warning.The Biome warning about "shadowing globalThis" is incorrect. Lines 27-29 use TypeScript's
declaresyntax to augment the global type with an additional property (__UPLOADTHING), not to declare a variable that shadows the global. This is a standard TypeScript pattern for extending global types.examples/minimal-tanstack-start/src/routes/api.uploadthing.ts (1)
1-16: LGTM! Route configuration properly migrated to TanStack Router's file-based routing API.The route correctly uses
createFileRoutewith the nestedserver.handlersstructure, replacing the previous server-only route pattern. Both GET and POST handlers are properly wired to the UploadThing route handler.examples/minimal-tanstack-start/src/router.tsx (1)
1-23: LGTM! SSR integration correctly implemented, but pipeline failure expected.The router setup properly integrates the new TanStack SSR plugin:
- Uses
createIsomorphicFn().server()to extract config server-side only- Calls
setupRouterSsrUploadThingIntegrationto wire SSR hydration/dehydration- Function rename from
createRoutertogetRouteris appropriate for a singleton patternThe pipeline failure ("Cannot find module '@uploadthing/react/tanstack-ssr-plugin'") is expected because the
tanstack-ssr-plugindirectory is not included in thefilesarray inpackages/react/package.json. This was flagged in the review of that file.The pipeline failure will resolve once
tanstack-ssr-pluginis added to the files array inpackages/react/package.json.examples/minimal-tanstack-start/src/routeTree.gen.ts (1)
1-86: Generated file is consistent with router changes.This file is auto-generated by TanStack Router (as noted in lines 7-9) and correctly reflects the migration of the
/api/uploadthingroute from a server-only route to a client route with server handlers. The new SSR module augmentation (lines 79-86) properly registers the router type withssr: true, consistent with the SSR integration setup inrouter.tsx.
| "@tanstack/react-router": "^1.141.2", | ||
| "@tanstack/react-start": "^1.141.3", | ||
| "@uploadthing/react": "7.3.3", | ||
| "react": "19.2.2", | ||
| "react-dom": "19.2.2", | ||
| "@vitejs/plugin-react": "^5.1.2", | ||
| "react": "19.2.3", | ||
| "react-dom": "19.2.3", | ||
| "uploadthing": "7.7.4" | ||
| }, | ||
| "devDependencies": { | ||
| "@types/react": "19.2.7", | ||
| "@types/react-dom": "19.2.3", | ||
| "typescript": "5.8.3", | ||
| "vite": "^6.3.4" | ||
| "typescript": "5.9.3", | ||
| "vite": "^7.2.7" |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
latest versions @tanstack/react-router @tanstack/react-start vite npm registry 2024 2025
💡 Result:
As of Dec 14, 2025 — latest npm-released versions (sources shown):
- @tanstack/react-router: 1.139.1. [1]
- @tanstack/react-start (aka TanStack Start): 1.134.9. [2]
- vite: 7.1.4. [3]
Sources:
[1] Release listings / package metadata (react-router). (newreleases.io)
[2] Package metadata / registry listing (react-start). (stacktco.com)
[3] vite package page on npm (version & publish date). (npmjs.com)
If you want exact publish dates or the npm registry JSON entries for each package, I can fetch and paste them.
Citations:
- 1: https://newreleases.io/project/npm/%40tanstack/react-router/release/1.22.6?utm_source=openai
- 2: https://www.stacktco.com/packages/%40tanstack/react-start?utm_source=openai
- 3: https://www.npmjs.com/package/vite?utm_source=openai
🌐 Web query:
@uploadthing/react uploadthing latest version npm
💡 Result:
As of December 14, 2025 the latest npm release of @uploadthing/react is 7.3.3. [1][2]
Sources:
[1] npm package page — @uploadthing/react (version 7.3.3).
[2] UploadThing docs (install instructions reference @uploadthing/react).
🌐 Web query:
@vitejs/plugin-react latest version npm
💡 Result:
Latest version: @vitejs/plugin-react 5.1.1 — released Nov 12, 2025. [1][2]
Sources:
[1] GitHub releases for vite-plugin-react. [2] Package info / registry summary.
Dependency versions need verification—several specified versions do not appear to exist in the npm registry.
The specified versions for @tanstack/react-router (^1.141.2) and @tanstack/react-start (^1.141.3) exceed the latest available versions (1.139.1 and 1.134.9 respectively as of December 2025). Similarly, vite (^7.2.7) is specified at a version newer than the current latest (7.1.4). These versions should be confirmed to ensure they are valid, or downgraded to versions that actually exist in the registry. @uploadthing/react (7.3.3) is current, but the other mismatches could cause installation or compatibility issues.
🤖 Prompt for AI Agents
In examples/minimal-tanstack-start/package.json around lines 12 to 24, several
dependency versions appear to not exist in the npm registry (notably
@tanstack/react-router ^1.141.2, @tanstack/react-start ^1.141.3, and vite
^7.2.7); update package.json to use valid published versions by checking npm
(for example set @tanstack/react-router to 1.139.1, @tanstack/react-start to
1.134.9, and vite to 7.1.4 or whatever the registry shows as latest/compatible),
run npm view or npm info to confirm exact versions, update the version strings
in the file, and then run npm install (or pnpm/yarn) to verify installation
succeeds and fix any resulting peer/compatibility issues.
| "next": "15.5.8", | ||
| "react": "19.2.2", | ||
| "react-dom": "19.2.2", | ||
| "next": "16.0.10", |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
Next.js 16.0.10 breaking changes release notes
💡 Result:
Here are the breaking changes noted for Next.js 16 (apply to 16.x, including 16.0.10):
- Async-only Request APIs: synchronous access removed — params, searchParams, cookies(), headers(), draftMode() must be awaited. [1]
- Minimum runtime bumps: Node.js now requires >= 20.9.0; TypeScript minimum bumped (e.g., 5.1+ referenced). [1][2]
- Middleware rename/behavior change: old middleware.ts paradigm changed (examples mention proxy.ts / clarified network boundary). [2]
- Removal of deprecated features: AMP support removed; some dev commands/legacy flags removed (e.g., experimental.ppr → cacheComponents, next lint guidance). [2][3]
- API behavior changes: certain APIs (e.g., revalidateTag()) require new arguments/profiles for stale-while-revalidate behavior; image/config defaults adjusted in v16 notes. [2][3]
- Migration tooling: automated codemods and typegen helpers recommended (npx @next/codemod@canary upgrade latest, npx next typegen). [1][3]
Sources: Next.js official upgrade docs for v16 (breaking-change details) [1]; InfoQ Next.js 16 release coverage (breaking changes summary) [2]; community migration writeup (async Request APIs emphasis) [3].
References
[1] Next.js — Upgrading: Version 16 (official docs).
[2] InfoQ — “Vercel’s Next.js 16: Explicit Caching, Turbopack Stability, and Improved Developer Tooling.”
[3] Michael Pilgram — “Migrating to Next.js 16: What Breaks, What Works, and When to Upgrade.”
Verify Next.js 16.0.10 compatibility for this example.
The jump from Next.js 15.5.8 to 16.0.10 is a major version bump with several breaking changes that require code updates:
- Async Request APIs:
params,searchParams,cookies(),headers(), anddraftMode()must now be awaited - Middleware changes: The middleware.ts paradigm has changed; verify any middleware in this example aligns with the v16 approach
- API behavior updates:
revalidateTag()and other caching APIs have new requirements for stale-while-revalidate behavior - Deprecated features removed: AMP support and legacy flags are no longer available
Use the automated migration tooling (npx @next/codemod@canary upgrade latest and npx next typegen) to help identify required changes in route handlers, middleware, metadata generation, and caching directives.
🤖 Prompt for AI Agents
In examples/with-react-image-crop/package.json around line 13, the project pins
Next.js to 16.0.10 which is a major upgrade from 15.5.8 and likely introduces
breaking changes; update the example to be compatible by running the automated
migrations (npx @next/codemod@canary upgrade latest and npx next typegen), then
audit and update code to await new async request APIs (params, searchParams,
cookies(), headers(), draftMode()), revise any middleware to follow Next.js 16
middleware patterns, adjust API and caching usages (revalidateTag() and
SWR/revalidate behavior), and remove or replace deprecated features—run the
codemod, apply the suggested fixes, run the app and tests, and commit the
resulting code changes and updated package.json if compatibility fixes were
required.
| "dependencies": { | ||
| "@tailwindcss/cli": "^4.1.18", | ||
| "@uploadthing/shared": "workspace:*", | ||
| "@vitest/browser-playwright": "^4.0.15", |
There was a problem hiding this comment.
Move @vitest/browser-playwright to devDependencies.
@vitest/browser-playwright is a testing tool and should not be in runtime dependencies. Library consumers don't need browser testing infrastructure installed as a production dependency.
Apply this diff:
"dependencies": {
"@tailwindcss/cli": "^4.1.18",
"@uploadthing/shared": "workspace:*",
- "@vitest/browser-playwright": "^4.0.15",
"file-selector": "0.6.0"
},And add it to devDependencies (it may already be listed there, in which case just remove from dependencies):
"devDependencies": {
"@tanstack/react-router": "^1.141.2",
"@tanstack/react-start": "^1.141.3",
...
+ "@vitest/browser-playwright": "^4.0.15",📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| "@vitest/browser-playwright": "^4.0.15", | |
| packages/react/package.json | |
| "dependencies": { | |
| "@tailwindcss/cli": "^4.1.18", | |
| "@uploadthing/shared": "workspace:*", | |
| "file-selector": "0.6.0" | |
| }, | |
| "devDependencies": { | |
| "@tanstack/react-router": "^1.141.2", | |
| "@tanstack/react-start": "^1.141.3", | |
| "@vitest/browser-playwright": "^4.0.15", | |
| ... | |
| } |
🤖 Prompt for AI Agents
In packages/react/package.json around line 79, the package
"@vitest/browser-playwright" is incorrectly listed under dependencies; move it
to devDependencies by removing the entry from "dependencies" and ensuring an
equivalent entry (matching the same version) exists under "devDependencies" — if
it already exists there, simply delete the dependency line at line 79; otherwise
add the package to devDependencies with the same version string and save the
updated package.json.
| "peerDependencies": { | ||
| "next": "*", | ||
| "react": "^17.0.2 || ^18.0.0 || ^19.0.0", | ||
| "react": "*", |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
# First, let's check the current state of packages/react/package.json
cat -n packages/react/package.json | sed -n '75,95p'Repository: pingdotgg/uploadthing
Length of output: 843
🏁 Script executed:
# Search for React 19-specific APIs in packages/react/src
rg -n "useActionState|useFormStatus|useOptimistic|use\(" packages/react/src --type ts --type tsx -C 2Repository: pingdotgg/uploadthing
Length of output: 92
🏁 Script executed:
# Check if there are any compatibility notes or React version constraints elsewhere
rg -n "react.*version|compatibility|upgrade.*react|React.*1[89]" packages/react --type ts --type tsx --type json -iRepository: pingdotgg/uploadthing
Length of output: 92
🏁 Script executed:
# Search for React 19-specific APIs with corrected rg syntax
rg -n "useActionState|useFormStatus|useOptimistic" packages/react/src -C 2Repository: pingdotgg/uploadthing
Length of output: 47
🏁 Script executed:
# Search for React imports and usage patterns
rg -n "from ['\"]react['\"]" packages/react/src -A 3 | head -100Repository: pingdotgg/uploadthing
Length of output: 2311
🏁 Script executed:
# Check for any React version constraints, compatibility notes, or discussions
rg -n "react.*version|peerDependencies|React.*18|React.*19" packages/react --type json -C 2Repository: pingdotgg/uploadthing
Length of output: 323
🏁 Script executed:
# Check the main exports and hook usage in core files
fd -e ts -e tsx . packages/react/src -type f | head -20Repository: pingdotgg/uploadthing
Length of output: 235
🏁 Script executed:
# Check for any runtime version checks or validation
rg -n "version|React.*support|compatibility|peerDependencies" packages/react/srcRepository: pingdotgg/uploadthing
Length of output: 963
🏁 Script executed:
# Look for README or documentation about React version support
fd README -i packages/react | head -5Repository: pingdotgg/uploadthing
Length of output: 89
🏁 Script executed:
# Check if there's any discussion about the wildcard in comments or config
rg -n "wildcard|peer.*depend|react.*any" packages/react -iRepository: pingdotgg/uploadthing
Length of output: 1288
🏁 Script executed:
# Verify what React versions these hooks are compatible with
# useRef, useState, useEffect, useReducer, useCallback, useMemo, useId, useServerInsertedHTML
# Let's check if useId or useServerInsertedHTML have any version requirements
rg -n "useId|useServerInsertedHTML" packages/react/src -B 2 -A 2Repository: pingdotgg/uploadthing
Length of output: 1192
🏁 Script executed:
# Check the warnIfInvalidPeerDependency implementation
rg -n "warnIfInvalidPeerDependency" packages -A 10 -B 2 | head -60Repository: pingdotgg/uploadthing
Length of output: 47
🏁 Script executed:
# Read the README to see if React version support is documented
cat packages/react/README.mdRepository: pingdotgg/uploadthing
Length of output: 1286
🏁 Script executed:
# Check the shared package for warnIfInvalidPeerDependency
rg -n "export.*warnIfInvalidPeerDependency|function warnIfInvalidPeerDependency" packages/shared/src -A 15Repository: pingdotgg/uploadthing
Length of output: 1069
🏁 Script executed:
# Check package.json history or any version-related comments in main files
head -100 packages/react/package.jsonRepository: pingdotgg/uploadthing
Length of output: 2764
Document the minimum React version or add runtime validation for the wildcard peer dependency.
The wildcard "*" for React peer dependency is intentional to support multiple React versions, and the codebase uses only React hooks (compatible with React 16.8+). However, without a documented minimum version or runtime validation, users could encounter silent failures with incompatible React versions (e.g., React 15). Consider either specifying a minimum version range (e.g., "^16.8.0" or "^18.0.0") or adding runtime validation similar to the uploadthing peer dependency check.
🤖 Prompt for AI Agents
In packages/react/package.json around line 83, the peerDependency currently uses
a wildcard "react": "*" which can allow incompatible React versions; update the
peerDependency to a minimum supported range (for example "react": ">=16.8.0 <19"
or a semver range like "^16.8.0 || ^17 || ^18") and add a short note in
package.json's description or README documenting the minimum supported React
version; alternatively (or in addition) implement a runtime version check in the
package entry point that reads React.version and throws a clear error
recommending the supported versions (mirroring the uploadthing check) so
consumers get a helpful failure instead of silent breakage.
There was a problem hiding this comment.
Actionable comments posted: 9
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (4)
packages/expo/src/index.ts (1)
68-71: Avoid logging environment variable values.The error message directly logs
process.env.EXPO_PUBLIC_SERVER_ORIGIN, which could expose sensitive information if the environment variable contains credentials, tokens, or other secrets. Even though this is a URL origin, it's a best practice to avoid logging environment variables.Consider sanitizing or omitting the environment variable value from the log:
console.warn( - `Failed to resolve URL from ${initOpts?.url?.toString()} and ${process.env.EXPO_PUBLIC_SERVER_ORIGIN} or ${debuggerHost}. Your application may not work as expected.`, + `Failed to resolve URL from ${initOpts?.url?.toString()} with configured environment variables. Your application may not work as expected.`, err, );packages/react/package.json (1)
48-63: Exported./tanstack-ssr-pluginwon’t be published (missing from"files").
"files"omitstanstack-ssr-plugin, so consumers can get a broken export map after publish."files": [ "dist", "native", - "next-ssr-plugin" + "next-ssr-plugin", + "tanstack-ssr-plugin" ],packages/expo/package.json (1)
44-57: React and React Native versions may be misaligned.
react(19.1.4) withreact-native(~0.81.5) creates a version mismatch: React Native 0.81 bundles React 19.0/19.1, but React Native 0.82+ is recommended for React 19.2 features. Additionally,@types/react(19.2.7) declares types for a newer version than the runtime react version (19.1.4), which may cause type inconsistencies.Also verify
expo-constants(^18.0.12): the caret allows versions up to 18.x, but Expo SDK bundles ~17.x. Consider pinning to match your target Expo SDK version.packages/nuxt/package.json (1)
39-51: Fix Nuxt 3.15.0 incompatibility with workspace Vite 7.2.7 override, or enable/fix test suite to catch it.The workspace
pnpm-workspace.yamloverridesviteto 7.2.7 globally, but Nuxt 3.15.0 officially supports only Vite 6.x. This creates a documented incompatibility that packages/nuxt will encounter at runtime. Additionally, the packages/nuxt test suite is disabled (scripts namedFIXME__testrather thantest), so CI does not detect this issue.Options: (1) change workspace override to
vite: ^6, (2) upgrade to a Nuxt version that supports Vite 7, or (3) rename and enable packages/nuxt tests (testscript) to detect the incompatibility early.
♻️ Duplicate comments (5)
examples/with-clerk-pagesdir/package.json (1)
18-19: React version downgrade is unusual—verify intentionality.The React and react-dom versions were downgraded from 19.2.2 to 19.1.4. While the matching versions fix the past incompatibility issue, a downgrade in a maintenance PR is atypical. Confirm this is intentional and that no critical bug fixes in 19.2.x are needed for your use case.
examples/with-clerk-appdir/package.json (1)
18-19: React version downgrade is unusual—verify intentionality.The React and react-dom versions were downgraded from 19.2.2 to 19.1.4. While the matching versions fix the past incompatibility issue, a downgrade in a maintenance PR is atypical. Confirm this is intentional and that no critical bug fixes in 19.2.x are needed for your use case.
packages/uploadthing/package.json (1)
176-176: Move test tool to devDependencies (duplicate of past issue).
@vitest/browser-playwrightis a testing tool and should be indevDependencies, notdependencies. This issue was previously flagged and remains unresolved.Apply this diff:
"dependencies": { "@effect/platform": "0.93.8", "@standard-schema/spec": "1.0.0-beta.4", "@uploadthing/mime-types": "workspace:*", "@uploadthing/shared": "workspace:*", - "@vitest/browser-playwright": "^4.0.15", "effect": "3.19.12" }, "devDependencies": { "@effect/vitest": "0.27.0", "@remix-run/server-runtime": "^2.17.2", "@types/body-parser": "^1.19.6", "@types/express": "^5.0.6", "@types/express-serve-static-core": "^5.1.0", "@types/react": "19.2.7", "@uploadthing/eslint-config": "workspace:*", "@uploadthing/tsconfig": "workspace:*", "@uploadthing/vitest-config": "workspace:*", + "@vitest/browser-playwright": "^4.0.15", "@vitest/coverage-istanbul": "4.0.15",packages/react/package.json (2)
83-85: React peerDependency wildcard is risky without a documented minimum (duplicate of prior feedback).#!/bin/bash set -euo pipefail # Quick sanity check: confirm docs/README states minimum React version somewhere. rg -n --hidden -S "minimum react|react (>=|\\^|~)|peerDependencies.*react" packages/react/README.md packages/react/package.json -C 2 || true
76-81: Move build/test tooling out of runtimedependencies.
This duplicates prior review feedback:@tailwindcss/cliand@vitest/browser-playwrightshouldn’t be installed by library consumers."dependencies": { - "@tailwindcss/cli": "^4.1.18", "@uploadthing/shared": "workspace:*", - "@vitest/browser-playwright": "^4.0.15", "file-selector": "0.6.0" }, "devDependencies": { + "@tailwindcss/cli": "^4.1.18", ... + "@vitest/browser-playwright": "^4.0.15", ... }#!/bin/bash set -euo pipefail # Verify nothing in packages/react runtime code shells out to tailwind/vitest tooling. rg -n --hidden -S "@tailwindcss/cli|browser-playwright|playwright" packages/react/src -C 2 || true
🧹 Nitpick comments (4)
examples/minimal-expo/app/_layout.tsx (1)
43-50: Either restorecssInterop(...)registrations or remove the now-misleading docs/types.Right now, the file still documents interop (Lines 39-42) and still adds
classNametypes (Lines 56-66), but runtime interop is disabled (Lines 43-50). If you intentionally dropped NativeWind interop for these components, I’d also remove or rewrite the block comment + module augmentations to avoid a “type says it works, runtime says it doesn’t” trap.If you intended to keep interop, restore the calls:
-// cssInterop(BottomSheetView, { className: "style" }); -// cssInterop(BottomSheetModal, { -// className: "style", -// bgClassName: "backgroundStyle", -// }); -// cssInterop(FeatherIcon, { className: "style" }); -// cssInterop(Image, { className: "style" }); -// cssInterop(RectButton, { className: "style" }); +cssInterop(BottomSheetView, { className: "style" }); +cssInterop(BottomSheetModal, { + className: "style", + bgClassName: "backgroundStyle", +}); +cssInterop(FeatherIcon, { className: "style" }); +cssInterop(Image, { className: "style" }); +cssInterop(RectButton, { className: "style" });Also worth double-checking NativeWind v4’s current recommendation for third-party components to ensure
cssInteropis still the right API.packages/react/package.json (1)
67-75: Keep repo-clean scripts in sync with new output dirs.
cleandoesn’t includetanstack-ssr-plugin, so local clean/build cycles may leave stale artifacts.- "clean": "git clean -xdf dist hooks native next-ssr-plugin node_modules", + "clean": "git clean -xdf dist hooks native next-ssr-plugin tanstack-ssr-plugin node_modules",examples/backend-adapters/server/package.json (1)
15-41: Optional: make versioning strategy consistent (pin vs caret).
You pin the Effect packages +uploadthingbut use carets for most others; if this is intentional (stability for core deps), all good—otherwise consider pinning more broadly (or using carets broadly) to reduce “works on my machine” drift.packages/nuxt/package.json (1)
31-33:FIXME__testscript name looks like a footgun (consider renaming totest).If the intent is “tests exist but are flaky,” consider renaming to
testand gating flakiness in CI with retries or quarantined tags; otherwise it’s easy for contributors/CI to miss running tests.
📜 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 (47)
docs/package.json(3 hunks)examples/backend-adapters/client-react/package.json(1 hunks)examples/backend-adapters/client-vanilla/package.json(1 hunks)examples/backend-adapters/client-vue/package.json(1 hunks)examples/backend-adapters/server/package.json(2 hunks)examples/minimal-appdir/package.json(1 hunks)examples/minimal-astro-react/package.json(1 hunks)examples/minimal-expo/app.config.ts(1 hunks)examples/minimal-expo/app/_layout.tsx(2 hunks)examples/minimal-expo/app/f/[key].tsx(1 hunks)examples/minimal-expo/app/styles.css(1 hunks)examples/minimal-expo/babel.config.js(0 hunks)examples/minimal-expo/index.ts(0 hunks)examples/minimal-expo/metro.config.js(1 hunks)examples/minimal-expo/nativewind-env.d.ts(1 hunks)examples/minimal-expo/package.json(1 hunks)examples/minimal-expo/postcss.config.mjs(1 hunks)examples/minimal-expo/tailwind.config.ts(0 hunks)examples/minimal-pagedir/package.json(1 hunks)examples/minimal-sveltekit/package.json(1 hunks)examples/minimal-tanstack-start/package.json(1 hunks)examples/profile-picture/package.json(2 hunks)examples/with-clerk-appdir/package.json(1 hunks)examples/with-clerk-pagesdir/package.json(1 hunks)examples/with-clerk-react-router/package.json(1 hunks)examples/with-drizzle-appdir/package.json(1 hunks)examples/with-drizzle-pagesdir/package.json(1 hunks)examples/with-react-image-crop/package.json(1 hunks)examples/with-serveractions/package.json(1 hunks)examples/with-tailwindcss/package.json(1 hunks)package.json(2 hunks)packages/expo/package.json(2 hunks)packages/expo/src/index.ts(1 hunks)packages/mime-types/package.json(7 hunks)packages/nuxt/package.json(1 hunks)packages/react/package.json(4 hunks)packages/shared/package.json(2 hunks)packages/solid/package.json(1 hunks)packages/svelte/package.json(1 hunks)packages/uploadthing/package.json(11 hunks)packages/vue/package.json(2 hunks)playground-v6/package.json(1 hunks)playground/package.json(1 hunks)pnpm-workspace.yaml(1 hunks)tooling/eslint-config/base.js(1 hunks)tooling/eslint-config/package.json(1 hunks)tooling/vitest-config/package.json(1 hunks)
💤 Files with no reviewable changes (3)
- examples/minimal-expo/babel.config.js
- examples/minimal-expo/tailwind.config.ts
- examples/minimal-expo/index.ts
🚧 Files skipped from review as they are similar to previous changes (16)
- examples/minimal-sveltekit/package.json
- examples/backend-adapters/client-react/package.json
- examples/minimal-tanstack-start/package.json
- tooling/vitest-config/package.json
- examples/backend-adapters/client-vanilla/package.json
- playground-v6/package.json
- playground/package.json
- examples/backend-adapters/client-vue/package.json
- examples/profile-picture/package.json
- examples/minimal-pagedir/package.json
- examples/with-tailwindcss/package.json
- examples/with-serveractions/package.json
- package.json
- packages/solid/package.json
- docs/package.json
- examples/with-clerk-react-router/package.json
🧰 Additional context used
🧠 Learnings (12)
📚 Learning: 2024-12-07T18:44:24.444Z
Learnt from: juliusmarminge
Repo: pingdotgg/uploadthing PR: 1090
File: docs/src/components/Code.tsx:135-137
Timestamp: 2024-12-07T18:44:24.444Z
Learning: In `docs/src/components/Code.tsx`, using type casts like `as any` is acceptable due to type mismatches between React 18 and 19. These casts will be addressed when the project upgrades to React 19.
Applied to files:
examples/minimal-expo/package.jsonexamples/with-drizzle-appdir/package.jsonexamples/with-clerk-pagesdir/package.jsonexamples/minimal-appdir/package.jsonexamples/minimal-astro-react/package.jsonpackages/react/package.jsonexamples/with-react-image-crop/package.json
📚 Learning: 2025-01-24T01:57:53.903Z
Learnt from: markflorkowski
Repo: pingdotgg/uploadthing PR: 1138
File: playground/package.json:27-27
Timestamp: 2025-01-24T01:57:53.903Z
Learning: When reviewing package versions, verify the latest version from the npm registry instead of making assumptions about version availability. Package versions can change frequently, and cached knowledge about versions can become outdated quickly.
Applied to files:
examples/minimal-expo/package.jsonexamples/with-drizzle-appdir/package.jsonexamples/with-clerk-pagesdir/package.jsonexamples/minimal-appdir/package.jsonpackages/react/package.jsonexamples/with-react-image-crop/package.json
📚 Learning: 2024-11-11T20:32:20.335Z
Learnt from: markflorkowski
Repo: pingdotgg/uploadthing PR: 1046
File: playground-v6/package.json:5-10
Timestamp: 2024-11-11T20:32:20.335Z
Learning: In the `playground-v6` project, the use of the experimental `--turbopack` flag is acceptable, and instability is expected.
Applied to files:
pnpm-workspace.yaml
📚 Learning: 2024-11-11T20:32:20.335Z
Learnt from: markflorkowski
Repo: pingdotgg/uploadthing PR: 1046
File: playground-v6/package.json:5-10
Timestamp: 2024-11-11T20:32:20.335Z
Learning: The `playground-v6` project is a testing playground and is not intended for production deployment, so a `start` script is unnecessary.
Applied to files:
pnpm-workspace.yaml
📚 Learning: 2024-11-11T20:32:20.334Z
Learnt from: markflorkowski
Repo: pingdotgg/uploadthing PR: 1046
File: playground-v6/package.json:5-10
Timestamp: 2024-11-11T20:32:20.334Z
Learning: In the `playground-v6` project, the `lint` script in `package.json` can be `"eslint"` without specifying the directory, as `eslint` defaults to `.`.
Applied to files:
pnpm-workspace.yaml
📚 Learning: 2024-11-11T20:10:04.389Z
Learnt from: markflorkowski
Repo: pingdotgg/uploadthing PR: 1046
File: playground-v6/components/uploader.tsx:19-21
Timestamp: 2024-11-11T20:10:04.389Z
Learning: In the 'playground' and 'playground-v6' directories, the code is intended for testing purposes and does not require additional complexity in error handling.
Applied to files:
pnpm-workspace.yaml
📚 Learning: 2024-11-11T19:59:56.512Z
Learnt from: markflorkowski
Repo: pingdotgg/uploadthing PR: 1046
File: playground-v6/app/layout.tsx:21-21
Timestamp: 2024-11-11T19:59:56.512Z
Learning: In the `playground-v6` project, using the Tailwind CSS CDN in `playground-v6/app/layout.tsx` is acceptable as it is a playground for testing purposes and not intended for production deployment.
Applied to files:
pnpm-workspace.yamlexamples/minimal-expo/postcss.config.mjsexamples/minimal-expo/app/styles.cssexamples/minimal-expo/app/_layout.tsxpackages/react/package.json
📚 Learning: 2024-11-05T17:11:33.300Z
Learnt from: juliusmarminge
Repo: pingdotgg/uploadthing PR: 1013
File: packages/mime-types/package.json:24-69
Timestamp: 2024-11-05T17:11:33.300Z
Learning: In this codebase, the bundler `bunchee` uses `package.json` as the source of truth for exports and outputs matching files during the build process. Therefore, the export paths specified in `package.json` align with the generated build output, even if the source files are located in a `src/` directory.
Applied to files:
packages/vue/package.jsonpackages/shared/package.jsonpackages/uploadthing/package.jsonpackages/react/package.jsonpackages/expo/package.jsonpackages/mime-types/package.json
📚 Learning: 2024-11-07T18:28:14.191Z
Learnt from: juliusmarminge
Repo: pingdotgg/uploadthing PR: 1046
File: playground/package.json:26-26
Timestamp: 2024-11-07T18:28:14.191Z
Learning: In `package.json`, the `typescript-eslint` package is correctly used and should not be replaced with `typescript-eslint/eslint-plugin` and `typescript-eslint/parser` in modern configurations.
Applied to files:
tooling/eslint-config/package.jsonpackages/uploadthing/package.jsonpackages/mime-types/package.json
📚 Learning: 2024-11-11T20:32:22.092Z
Learnt from: markflorkowski
Repo: pingdotgg/uploadthing PR: 1046
File: playground-v6/package.json:21-28
Timestamp: 2024-11-11T20:32:22.092Z
Learning: As of November 2024, ESLint version 9.x is the current stable release, and version 8.x is end-of-life (EOL). When suggesting ESLint version changes, ensure recommendations reflect the current stable version.
Applied to files:
tooling/eslint-config/package.json
📚 Learning: 2024-11-07T18:28:00.237Z
Learnt from: juliusmarminge
Repo: pingdotgg/uploadthing PR: 1046
File: playground/package.json:8-8
Timestamp: 2024-11-07T18:28:00.237Z
Learning: In projects using ESLint v9, the `lint` script in `package.json` does not need to specify a path or pattern, as ESLint v9 uses a default path.
Applied to files:
tooling/eslint-config/package.jsonpackages/mime-types/package.json
📚 Learning: 2025-01-03T17:49:32.484Z
Learnt from: juliusmarminge
Repo: pingdotgg/uploadthing PR: 1099
File: packages/solid/src/utils/createFetch.ts:15-19
Timestamp: 2025-01-03T17:49:32.484Z
Learning: "createFetch" in packages/solid/src/utils/createFetch.ts is considered an internal function, so changes to its signature are not covered by semver guarantees.
Applied to files:
packages/shared/package.json
⏰ 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)
- GitHub Check: bundle-analyze-result
- GitHub Check: lint
- GitHub Check: build
- GitHub Check: build
🔇 Additional comments (37)
examples/minimal-astro-react/package.json (2)
18-19: Verify React downgrade from 19.2.2 to 19.1.4.The branch is named
bump-deps, but React and React-DOM are being downgraded to an older minor version. This is unusual and suggests either a regression in 19.2.2 or a compatibility issue with Astro v5.1.2.Please clarify the motivation for this downgrade and confirm it resolves any blocking issues. If there's a known regression in 19.2.2, consider documenting it or opening an issue with the React team if not already reported.
23-23: Minor version updates are compatible.The updates to
@astrojs/check(0.9.4 → 0.9.6) andtypescript(5.8.3 → 5.9.3) are routine patch/minor bumps and align with the Astro v5 and React 19 support expectations documented in their respective changelogs.Also applies to: 26-26
examples/with-drizzle-appdir/package.json (3)
20-21: Verify the React version downgrade.React and react-dom have been downgraded from 19.2.2 to 19.1.4. This is unusual for a maintenance PR and breaks the typical upgrade pattern. Please clarify the reason:
- Is this an intentional rollback due to compatibility issues with a dependency?
- Are there known issues with 19.2.x in this example project?
Alternatively, if this is unintentional, the versions should be updated to the latest stable 19.2.x or 19.3.x line.
10-10: Lint script change aligns with tooling upgrades.The lint script has been updated from
"next lint"to"eslint src", which is consistent with the broader refactoring of lint tooling across the repository (ESLint upgraded from 9.25.1 to 9.39.2). Confirm thateslint-config-next15.5.9 properly shares its configuration with the local ESLint setup via.eslintrcor similar.
16-16: Dependency version updates are reasonable overall.The updates to
@t3-oss/env-nextjs, Next.js (patch bump), TypeScript, ESLint, and related tooling appear appropriate for maintenance work. React and react-dom versions now match (both 19.1.4), which resolves the version mismatch issue flagged in prior reviews.Also applies to: 19-19, 26-32
examples/with-clerk-pagesdir/package.json (2)
25-25: @types/node major version bump may introduce breaking changes.The update from ^22.10.0 to ^25.0.2 is a significant major version jump (Node.js types v22 → v25). This can introduce breaking changes in type definitions for runtime APIs. Verify that your codebase and dependencies are compatible with Node.js types v25, or test the build locally to ensure no type errors arise.
9-9: Lint script behavior change:next lint→eslint src.The lint script was switched from Next.js's wrapped linter to direct ESLint invocation. This may alter caching behavior, included rules, or path coverage compared to
next lint. Confirm that:
- ESLint configuration (if present) covers all necessary paths.
- The
eslint-config-nextdependency is still being used correctly.- No Next.js-specific lint rules are now being skipped.
examples/with-clerk-appdir/package.json (2)
25-25: @types/node major version bump may introduce breaking changes.The update from ^22.10.0 to ^25.0.2 is a significant major version jump (Node.js types v22 → v25). This can introduce breaking changes in type definitions for runtime APIs. Verify that your codebase and dependencies are compatible with Node.js types v25, or test the build locally to ensure no type errors arise.
9-9: Lint script behavior change:next lint→eslint src.The lint script was switched from Next.js's wrapped linter to direct ESLint invocation. This may alter caching behavior, included rules, or path coverage compared to
next lint. Confirm that:
- ESLint configuration (if present) covers all necessary paths.
- The
eslint-config-nextdependency is still being used correctly.- No Next.js-specific lint rules are now being skipped.
examples/minimal-expo/metro.config.js (1)
1-7: LGTM! Clean simplification of the Metro config.The configuration has been appropriately simplified to use the standard Expo + Nativewind integration pattern. Removing the monorepo-specific customizations (path handling, Turborepo cache) makes this example more accessible and easier to understand while still providing the necessary functionality.
packages/svelte/package.json (1)
45-59: Tailwind v4 migration complete and correct.All package.json updates are properly configured:
- ✓ Tailwind v4.1.18 with correct v4 plugins (@tailwindcss/cli, @tailwindcss/vite)
- ✓ PostCSS removed (v4 handles CSS internally)
- ✓ @sveltejs/vite-plugin-svelte ^6.2.1 supports Vite 7
- ✓ styles.css migrated to v4 import syntax with proper layer() declarations
- ✓ vite.config.ts includes @tailwindcss/vite plugin
- ✓ No legacy @tailwind directives remain
examples/minimal-expo/app/_layout.tsx (1)
9-9: File not found in repository. The referenced fileexamples/minimal-expo/app/_layout.tsxdoes not exist in this codebase. The uploadthing repository does not contain React Native/Expo examples. Verify that this review comment is intended for the correct repository and PR.Likely an incorrect or invalid review comment.
examples/minimal-expo/nativewind-env.d.ts (2)
3-3: Clarify whether this file was auto-generated or manually edited.The comment indicates this file is auto-generated by react-native-css and should not be manually edited. However, given this appears in a PR for manual repository maintenance, please confirm:
- Was this file regenerated by running a react-native-css command?
- Or was it manually updated to reflect the package migration?
If it was manually edited, consider regenerating it properly using the react-native-css CLI to ensure consistency. If it was auto-generated, the PR workflow looks correct.
1-1: No actionable changes needed. The types reference toreact-native-css/typesis correct and auto-generated by react-native-css (as noted in the file comment). Bothnativewind(v5.0.0-preview.2) andreact-native-css(v3.0.1) are properly installed in the example project. This setup is consistent with NativeWind v5's architecture, which integrates with react-native-css. The file should remain as-is per the auto-generated comment directive.examples/minimal-expo/package.json (3)
35-36: React and React-DOM versions are correctly aligned.Both packages specify version
19.1.4, ensuring consistency and avoiding peer dependency warnings. This resolves the prior mismatch issue.
35-36: Verify React version against npm registry.React
19.1.4is specified. The npm "latest" tag for React currently points to 19.1.1, making 19.1.4 a more recent patch version. While React 19.2.x versions have been released, the npm registry's "latest" tag has not yet been updated to point to them. Confirm whether19.1.4or a later 19.2.x version is the appropriate choice for this project's compatibility and support requirements.
34-34: Consider using a stable release of nativewind instead of a preview version.Line 34 specifies
nativewindat5.0.0-preview.2, a pre-release version. The latest stable release is v4.1.23. Preview versions carry higher risk of breaking changes and incompatibilities. If v5 is intentionally being tested, verify thorough testing in your project; otherwise, pin to the stable v4.1.23 release.⛔ Skipped due to learnings
Learnt from: markflorkowski Repo: pingdotgg/uploadthing PR: 1138 File: playground/package.json:27-27 Timestamp: 2025-01-24T01:57:53.903Z Learning: When reviewing package versions, verify the latest version from the npm registry instead of making assumptions about version availability. Package versions can change frequently, and cached knowledge about versions can become outdated quickly.examples/minimal-expo/postcss.config.mjs (1)
3-3: LGTM — Correct Tailwind v4 plugin name.The migration from
tailwindcssto@tailwindcss/postcssis correct for Tailwind CSS v4. The related CSS file (examples/minimal-expo/app/styles.css) has also been properly updated to use the new import syntax with layer directives (@import "tailwindcss/theme.css" layer(theme), etc.).packages/uploadthing/package.json (1)
139-142: Confirm the./typesexport structure change.The
./typesexport now uses a flat structure with"types"and"default"keys instead of nested"import"and"require"objects like the other exports. Verify this is intentional and properly aligns with your module resolution strategy for this export.tooling/eslint-config/base.js (1)
118-123: LGTM! Good addition for monorepo TypeScript resolution.Adding
tsconfigRootDiralongsideprojectService: trueensures TypeScript ESLint correctly resolvestsconfig.jsonfiles when ESLint is executed from different working directories in the monorepo. The use ofimport.meta.dirnameis appropriate for ESM modules.Note:
import.meta.dirnamerequires Node.js 20.11.0+. Ensure the project's minimum Node.js version is documented if not already specified.tooling/eslint-config/package.json (1)
15-16: All dependency versions are valid and current.The specified versions exist in the npm registry and are all at their latest releases:
@typescript-eslint/[email protected],@typescript-eslint/[email protected],[email protected],[email protected], and[email protected]. ESLint 9.39.2 aligns with the current stable release line. No version conflicts are present.packages/react/package.json (1)
12-57: The ESM/CJS export map with.d.mts/.d.ctsvariants is correctly configured. Thetsdown.config.tsdeclares all four entry points (dist/index, native/index, next-ssr-plugin/index, tanstack-ssr-plugin/index) withformat: ["esm", "cjs"]anddtsenabled, which will generate the matching.mjs,.cjs,.d.mts, and.d.ctsfiles. The CSS file is generated via theonSuccesshook. The package.json exports align with the build configuration.packages/shared/package.json (2)
13-14: Export paths correctly align with ESM migration.The module/typings and export mappings correctly follow the ESM migration pattern (
.mjs/.mtsfor imports,.cjs/.ctsfor requires). Per the retrieved learning, bunchee uses thispackage.jsonas the source of truth for build outputs, so these paths should align with generated artifacts.Also applies to: 19-20
56-56: Verify the react version downgrade.Line 56 shows
react: 19.2.2 → 19.1.4, which is a downgrade within the same minor version. The PR title mentions "bump-deps," but this appears to be a downgrade. Please confirm:
- Is this intentional (e.g., reverting to a more stable version)?
- Or is this a mistake and should be upgraded to a newer version?
examples/backend-adapters/server/package.json (2)
16-17: The Effect package versions are compatible. According to the npm registry:
@effect/[email protected]requireseffect@^3.19.12(you have 3.19.12 ✓)@effect/[email protected]requires@effect/platform@^0.93.6(you have 0.93.8 ✓) andeffect@^3.19.8(you have 3.19.12 ✓)All peer dependencies are satisfied and there are no version conflicts.
34-40: TS/tsx toolchain is compatible—no action needed.Verified that the repo's Node engine requirement (
^24.10.0in rootpackage.json) fully supports both[email protected]andtsx@^4.19.2(which requires Node ≥18.0.0). Thetsconfig.jsoninexamples/backend-adapters/serveruses standard, compatible settings (target: esnext,module: Preserve). CI is configured to read Node version frompackage.jsonand runs thebuildscript (invokingtsc) as part of the examples E2E workflow without issue.examples/minimal-expo/app.config.ts (1)
31-36: No action required—configuration is appropriate and supported.Both
reactCanaryandreactCompilerare now stable and officially supported. React Compiler v1.0 is stable and supported in Expo SDK 54+ (your example usesexpo ~54.0.29withreact 19.1.4), where it is enabled by default. The combination of these experimental flags is a recommended configuration for new Expo projects, not a stability concern.pnpm-workspace.yaml (1)
7-12: Consider upgrading React/react-dom to 19.2.0 and lightningcss to 1.30.2.The workspace overrides include versions from several months ago. Two packages have newer stable releases available:
- React/react-dom 19.1.4 → upgrade to 19.2.0 (released Oct 1, 2025). This minor version bump should be reviewed for compatibility with your monorepo.
- lightningcss 1.30.1 → consider upgrading to 1.30.2 (released Sept 29, 2025).
Vite 7.2.7 and srvx 0.9.8 are both current as of December 2025.
⛔ Skipped due to learnings
Learnt from: markflorkowski Repo: pingdotgg/uploadthing PR: 1138 File: playground/package.json:27-27 Timestamp: 2025-01-24T01:57:53.903Z Learning: When reviewing package versions, verify the latest version from the npm registry instead of making assumptions about version availability. Package versions can change frequently, and cached knowledge about versions can become outdated quickly.examples/with-drizzle-pagesdir/package.json (2)
10-10: This lint script is correctly configured for ESLint 9 with Next.js 15.The project uses direct ESLint CLI invocation with flat config (
eslint.config.js), which is a documented and valid approach. The setup properly usesFlatCompatto extend Next.js presets and has all required dependencies. Whilenext lintis also a valid option, the current implementation follows the repo's convention across all examples and doesn't need changes. Optionally, you could simplify to"eslint"(withoutsrc) since ESLint v9 defaults to the current directory.
27-33: No toolchain compatibility issues found.
ESLint 9.39.2 is officially supported by Next.js 15.5.9 (and later versions). The repository already uses the moderneslint.config.jsflat config format, which is the standard approach for ESLint 9. No migration or legacy.eslintrchandling is needed. @types/node 25.0.2 is compatible with TypeScript 5.9.3.Likely an incorrect or invalid review comment.
packages/vue/package.json (2)
49-49: No action required. The Tailwind CSS v4 upgrade is compatible with this package.This package uses a prop-based styling system for Vue components rather than hardcoded Tailwind classes. The
styles.cssfile contains only standard Tailwind imports with no custom syntax that requires v4 migration. The Tailwind CLI build process (v4) will work correctly with the existing setup. TypeScript 5.9.3 and ESLint 9.39.2 updates are also safe.
13-14: No action needed — the configuration correctly generates the configured output files.The
tsdownconfiguration intsdown.config.tsexplicitly setsformat: ["esm", "cjs"]and enablesdts, which tells tsdown to generate both ESM and CommonJS outputs with their corresponding type declarations. Thetsdownbundler automatically generates.d.mtsfor ESM declarations and.d.ctsfor CommonJS declarations per TypeScript conventions, matching the export paths specified inpackage.json.examples/minimal-appdir/package.json (2)
14-15: Version mismatch resolved: react and react-dom now correctly aligned.The react and react-dom dependencies are now properly matched at version 19.1.4, resolving the previous critical issue where they were mismatched (19.2.3 vs 19.2.2).
13-13: Verify dependency version compatibility and availability.All specified versions exist on npm. However, note the type definition version skew: @types/[email protected] is newer than the runtime [email protected]. While this typically works, it can occasionally cause type mismatches depending on breaking changes in type definitions—consider pinning @types/react to 19.1.x series for closer alignment with the runtime version, or upgrading react to 19.2.x/19.3.x if those versions are stable and compatible with Next.js 15.5.9.
⛔ Skipped due to learnings
Learnt from: markflorkowski Repo: pingdotgg/uploadthing PR: 1138 File: playground/package.json:27-27 Timestamp: 2025-01-24T01:57:53.903Z Learning: When reviewing package versions, verify the latest version from the npm registry instead of making assumptions about version availability. Package versions can change frequently, and cached knowledge about versions can become outdated quickly.Learnt from: juliusmarminge Repo: pingdotgg/uploadthing PR: 1090 File: docs/src/components/Code.tsx:135-137 Timestamp: 2024-12-07T18:44:24.444Z Learning: In `docs/src/components/Code.tsx`, using type casts like `as any` is acceptable due to type mismatches between React 18 and 19. These casts will be addressed when the project upgrades to React 19.packages/expo/package.json (1)
52-53: React 19.1.4 is fully compatible with React Native 0.81.x — React Native has shipped React 19 across 0.78+ releases and 0.81 continues with that support. No compatibility issue here.If there's an intentional change to the peer dependency
"react": "*"(line 63), clarify the rationale, but this is a separate concern from the React/React Native version compatibility itself.Likely an incorrect or invalid review comment.
examples/with-react-image-crop/package.json (2)
14-15: Clarify the React and React-DOM version downgrade.The package.json shows a downgrade from
19.2.2to19.1.4for both React and React-DOM. This is unusual and differs from typical dependency maintenance patterns.Please clarify whether this downgrade is intentional across the monorepo (e.g., due to a regression in 19.2.2, compatibility constraints with Next.js 15.5.9, or another reason).
20-20: Remove or downgrade @types/node to match Next.js 15.5.9's supported Node.js versions.The installed @types/node ^25.0.2 targets Node.js v25, but Next.js 15.5.9 supports only Node.js ^18.18.0 || ^19.8.0 || >=20.0.0. This creates a type definition mismatch: the types describe APIs available in Node 25, but your runtime may be Node 18–22.
Use @types/node aligned with your actual runtime: ^18 for Node 18.18+, ^20 for Node 20+, or ^22 for Node 22+. For example, change to
"@types/node": "^22.0.0"if targeting Node 22.⛔ Skipped due to learnings
Learnt from: juliusmarminge Repo: pingdotgg/uploadthing PR: 1090 File: docs/src/components/Code.tsx:135-137 Timestamp: 2024-12-07T18:44:24.444Z Learning: In `docs/src/components/Code.tsx`, using type casts like `as any` is acceptable due to type mismatches between React 18 and 19. These casts will be addressed when the project upgrades to React 19.
| return ( | ||
| <> | ||
| <Stack.Screen options={{ title: name, headerBackTitleVisible: false }} /> | ||
| <Stack.Screen options={{ title: name, headerBackVisible: false }} /> |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
# First, let's read the file to understand the context around line 17
cat -n examples/minimal-expo/app/f/[key].tsxRepository: pingdotgg/uploadthing
Length of output: 186
🌐 Web query:
expo-router 6.0.19 headerBackVisible Stack.Screen options support
💡 Result:
Yes — expo-router (Stack) supports headerBackVisible on Stack.Screen options (it uses React Navigation's native-stack under the hood). It will hide/show the header back button and has no effect on the first screen in the stack.
Example:
import { Stack } from 'expo-router';
export default function Layout() {
return (
<Stack.Screen name="details" options={{ headerBackVisible: false }} />
);
}
Sources: Expo Router docs (Stack header options). [1] React Navigation native-stack docs (headerBackVisible). [2]
References
[1] Expo Router — Stack (header options).
[2] React Navigation — Native Stack Navigator (headerBackVisible).
Ensure users can still navigate back after hiding the header back button
headerBackVisible: false hides the back button in the header. This option is supported in expo-router, but make sure users still have a way to go back—either through gesture navigation, hardware back button, or a custom headerLeft action. (Note: this option has no effect if this is the first screen in the stack.)
🤖 Prompt for AI Agents
In examples/minimal-expo/app/f/[key].tsx around line 17, the Stack.Screen sets
headerBackVisible: false which removes the header back button; update the screen
options so users still can navigate back by either (1) only setting
headerBackVisible: false when the screen is not the first in the stack, (2)
enable gesture navigation (gestureEnabled: true) so swipes work on iOS/Android,
and/or (3) provide a custom headerLeft that calls navigation.goBack() or
router.back(); additionally ensure Android hardware back is respected (handle
BackHandler or rely on navigation container) so there is always at least one
working back action.
| @import "tailwindcss/theme.css" layer(theme); | ||
| @import "tailwindcss/preflight.css" layer(base); | ||
| @import "tailwindcss/utilities.css"; | ||
|
|
||
| @import "nativewind/theme"; |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
NativeWind Tailwind CSS v4 configuration guide
💡 Result:
Quick config guide — NativeWind + Tailwind CSS v4
- Install dependencies
- npm install nativewind tailwindcss@^4 react-native-reanimated react-native-safe-area-context. Adjust versions for Expo/CLI as needed. [1][2]
- Create Tailwind config
- npx tailwindcss init
- Ensure tailwind.config.js has a content glob covering your RN/Expo files:
module.exports = { content: ["./App.{js,jsx,ts,tsx}", "./**/*.{js,jsx,ts,tsx}"], theme:{extend:{}}, plugins:[] } . [1]
- Replace Tailwind v3 directives with v4 imports in your global CSS
- Example global.css (Tailwind v4):
@import "tailwindcss/theme.css" layer(theme);
@import "tailwindcss/preflight.css" layer(base);
@import "tailwindcss/utilities.css";
@import "nativewind/theme";
This is required for Tailwind v4-style build output. [3]
- NativeWind build/metro integration
- Use NativeWind’s configuration/wrappers so Metro or Tailwind CLI generates native styles. See NativeWind’s configuration options (input, configFile, outputDir, inlineNativeRem, etc.) and the withNativeWind helper where applicable. If your project still uses the Babel approach, follow NativeWind docs for the recommended runtime/transform for v4. [1][2]
- Optional: rem handling & migration notes
- v4 supports rem inlining (inlineNativeRem option). If migrating from older NativeWind versions follow the official migration notes (remove TailwindProvider, ensure tailwind.config.js required, update CSS imports). [2][3]
- Verify
- Run the Tailwind CLI or start your bundler/dev server. Check that classes applied to native components produce styles and that hot-reload responds to tailwind.config changes. Consult NativeWind docs for platform-specific steps (Expo, framework-less, Next.js). [1]
References
- NativeWind configuration & docs. [1]
- NativeWind v4 announcement (architecture & rem support). [2]
- NativeWind v5 migration notes demonstrating Tailwind v4 import patterns. [3]
If you want, I can generate a ready-to-run example repo config (package.json, tailwind.config.js, global.css, and metro/babel snippets).
🌐 Web query:
NativeWind @import layer utilities CSS v4
💡 Result:
Short answer — for Tailwind CSS v4 with NativeWind you must switch from @tailwind directives to CSS @import layer imports and include NativeWind's theme. Example global CSS:
-
Replace:
@tailwind base;
@tailwind components;
@tailwind utilities; -
With (v4 style):
@import "tailwindcss/theme.css" layer(theme);
@import "tailwindcss/preflight.css" layer(base);
@import "tailwindcss/utilities.css";
@import "nativewind/theme";
Notes:
- v4 uses @import + layer(...) / new @utility/@utility-name rules instead of @layer utilities; @apply semantics changed in some cases (custom utilities/components may need defining with @Utility or moved to components). See migration guidance. [1][2][3]
Sources:
[1] NativeWind migration guide (v4 → v5 example showing v4 imports).
[2] Tailwind v4 docs / beta notes on using @import and @Utility.
[3] Community discussion (Stack Overflow / threads) about @apply differences and @layer → @Utility changes.
🏁 Script executed:
# Find and examine package.json in minimal-expo to check versions
find . -path "*/minimal-expo/package.json" -type f | head -1 | xargs cat 2>/dev/nullRepository: pingdotgg/uploadthing
Length of output: 1756
🏁 Script executed:
# Search for other CSS files with Tailwind imports to compare patterns
rg -t css "@import.*tailwindcss" --max-count=20Repository: pingdotgg/uploadthing
Length of output: 1143
Add layer(utilities) to line 3 for consistency with NativeWind integration pattern.
The import pattern is correct for NativeWind + Tailwind v4 integration (documented in NativeWind's official setup guide). However, line 3 should include the explicit layer declaration to match the pattern used elsewhere in the codebase (packages/vue, packages/svelte, packages/react, packages/solid all use layer(utilities)):
@import "tailwindcss/utilities.css" layer(utilities);🤖 Prompt for AI Agents
In examples/minimal-expo/app/styles.css around lines 1 to 5, the third import of
tailwind utilities is missing the explicit layer declaration; update the line to
import "tailwindcss/utilities.css" with layer(utilities) so it reads the same
pattern as other packages (i.e., add layer(utilities) to that import) to ensure
consistency with NativeWind/Tailwind v4 integration.
| "dependencies": { | ||
| "@libsql/client": "^0.14.0", | ||
| "@t3-oss/env-nextjs": "^0.11.1", | ||
| "@t3-oss/env-nextjs": "^0.13.8", |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
@t3-oss/env-nextjs 0.13.8 release notes breaking changes
💡 Result:
Breaking change in v0.13.8
- Presets (e.g., vercel) are now functions — update any usage like extends: [vercel] to extends: [vercel()]. See migration example. [1][2]
References
- Release notes / changelog (shows BREAKING: make env presets functions + migration snippet). [1]
- T3 Env docs / package info. [2]
@t3-oss/env-nextjs 0.13.8 has a breaking change: presets are now functions.
Update any preset usage from extends: [vercel] to extends: [vercel()]. See the release notes for the migration example.
🤖 Prompt for AI Agents
In examples/with-drizzle-pagesdir/package.json around line 16, the dependency
@t3-oss/env-nextjs v0.13.8 introduced a breaking change where presets are
functions; update any config usage that currently uses extends: [vercel] to call
the preset as a function extends: [vercel()] (and similarly for other presets),
e.g., change occurrences in your Next.js env config files to use the function
form and run a quick lint/format to ensure syntax is valid.
| "module": "dist/index.mjs", | ||
| "typings": "dist/index.d.cts", |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
cat packages/expo/package.jsonRepository: pingdotgg/uploadthing
Length of output: 1771
🏁 Script executed:
# Check tsdown configuration in packages/expo
find packages/expo -name "tsdown.config.*" -o -name "tsconfig.json" 2>/dev/null | head -10
# Also check for build outputs in dist directory structure
find packages/expo/dist -type f 2>/dev/null | head -20 || echo "dist directory not found or empty"
# Check root tsdown config that might apply
find . -maxdepth 2 -name "tsdown.config.*" 2>/dev/nullRepository: pingdotgg/uploadthing
Length of output: 123
🏁 Script executed:
cat packages/expo/tsdown.config.tsRepository: pingdotgg/uploadthing
Length of output: 279
🏁 Script executed:
# Search for all packages with "type": "module" and their typings configuration
rg -A 2 '"type":\s*"module"' --type json packages/*/package.json | grep -E '(package\.json|"typings"|"module")'Repository: pingdotgg/uploadthing
Length of output: 1303
🏁 Script executed:
# Check typings field in key packages
for pkg in react uploadthing shared expo; do
echo "=== packages/$pkg ==="
rg '"(typings|module)"' packages/$pkg/package.json -A 0 | head -5
doneRepository: pingdotgg/uploadthing
Length of output: 400
🏁 Script executed:
# Check packages/react and packages/uploadthing exports configurations
echo "=== packages/react exports ==="
jq '.exports, .typings, .module' packages/react/package.json 2>/dev/null || cat packages/react/package.json | head -40
echo ""
echo "=== packages/uploadthing exports ==="
jq '.exports, .typings, .module' packages/uploadthing/package.json 2>/dev/null || (cat packages/uploadthing/package.json | head -40)Repository: pingdotgg/uploadthing
Length of output: 4167
🌐 Web query:
ESM-first package.json typings field best practices conditional exports
💡 Result:
Summary best practices for ESM-first packages with typings + conditional exports
-
Use "exports" with a types condition (types must come first). This is required for TS to resolve declarations when exports is present. Example:
{
"type": "module",
"exports": {
".": {
"types": "./dist/index.d.mts",
"import": "./dist/index.mjs",
"require": "./dist/index.cjs",
"default": "./dist/index.mjs"
}
},
"main": "./dist/index.cjs" /* CJS fallback for older Node/consumers */
}
(TS expects the "types" condition to be the first property). [1][2][3] -
Ship separate declaration files for ESM and CJS entrypoints. TypeScript treats .d.mts/.d.cts (or .d.ts interpreted by nearest package.json "type") differently — you cannot reliably reuse a single .d.ts for both module kinds if you publish dual entrypoints. Use .d.mts for ESM and .d.cts for CJS, or colocated .d.js-adjacent files. If the API has no default export, the ESM .d.mts may re-export from the CJS .d.cts to avoid duplication. [1][4]
-
Set package.json "type":"module" for ESM-first packages and name files with .mjs/.cjs (or rely on "type"). Ensure declaration file extensions match the module kind so TS interprets them correctly. [1][3]
-
Keep a "main" and root "types" fallback for older Node/TS tooling, but prefer the exports.types path for modern resolution. Example fallback:
"main": "./dist/index.cjs",
"types": "./dist/index.d.ts" // older-tooling fallback only
(Modern TS uses the types subfield in exports if exports exists; root "types" is ignored by TS resolution when exports is present.) [1][3][4] -
Configure your build to emit declaration files with correct extensions and paths:
- ESM JS -> .mjs and types -> .d.mts
- CJS JS -> .cjs and types -> .d.cts
- If using plain .js + "type": "module", provide .d.mts for ESM consumers. [1][0]
-
TypeScript consumer settings: advise library users to use TS >= 4.7 and moduleResolution node16/nodenext (or bundler) for correct exports-aware resolution. If you need max compatibility, document this in README. [2][5]
-
Test resolution in real projects and with bundlers (esbuild/webpack/rollup), and run publint / similar checks for export/types mismatches (these tools surface common mistakes). [0]
Key references
- TypeScript docs (exports + types condition, and per-entry declaration rules). [1][3]
- Practical guide / blog posts on TS + package.json exports. [4]
- publint rule notes on .d.mts / .d.cts behavior and examples. [0]
- Notes about TS support (TS 4.7+) and consumers' tsconfig requirements. [2][5]
If you want, I can:
- produce a ready-to-publish package.json + tsconfig + build script example for an ESM-first library (with both .mjs/.cjs outputs and .d.mts/.d.cts typings).
🏁 Script executed:
# Check if there are any built packages to verify tsdown output
find . -path "*/dist/index.d.*" -type f 2>/dev/null | head -20Repository: pingdotgg/uploadthing
Length of output: 47
Top-level typings field is inconsistent with ESM-first package configuration.
The package declares "type": "module" (line 4). The exports field correctly specifies conditional types—ESM consumers get dist/index.d.mts, CJS consumers get dist/index.d.cts. However, the top-level typings field (line 13) points to dist/index.d.cts (the CJS variant). While modern TypeScript 4.7+ uses the exports field and ignores this fallback, the top-level typings field should align with the ESM default for clarity and compatibility with older tooling. This pattern is also inconsistent with other ESM-first packages in the repo (e.g., packages/react, packages/uploadthing) which omit this field entirely.
Consider either removing the top-level typings field or updating it to point to dist/index.d.mts.
🤖 Prompt for AI Agents
In packages/expo/package.json around lines 12 to 13, the top-level "typings"
field points to the CJS declaration (dist/index.d.cts) which contradicts the
package's ESM-first "type": "module" and the conditional types in "exports";
either remove the top-level "typings" field entirely or change it to the ESM
declaration (dist/index.d.mts) so the top-level typings align with the ESM
default and match other ESM-first packages in the repo.
packages/expo/src/index.ts
Outdated
| : ((process.env.EXPO_PUBLIC_SERVER_ORIGIN as string | undefined) ?? | ||
| `http://${debuggerHost}`), |
There was a problem hiding this comment.
Type cast improves clarity.
The explicit cast to string | undefined makes the intent clearer, even though process.env.* typically has this type by default. This defensive typing can be helpful for certain build configurations.
However, be aware that if EXPO_PUBLIC_SERVER_ORIGIN is set to an empty string "", the nullish coalescing operator ?? will NOT fall back to the debugger host, since empty strings are not nullish. This could cause the new URL() constructor to fail.
Consider using the logical OR operator || instead to handle empty strings, or add explicit validation:
- : ((process.env.EXPO_PUBLIC_SERVER_ORIGIN as string | undefined) ??
- `http://${debuggerHost}`),
+ : ((process.env.EXPO_PUBLIC_SERVER_ORIGIN as string | undefined)?.trim() ||
+ `http://${debuggerHost}`),📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| : ((process.env.EXPO_PUBLIC_SERVER_ORIGIN as string | undefined) ?? | |
| `http://${debuggerHost}`), | |
| : ((process.env.EXPO_PUBLIC_SERVER_ORIGIN as string | undefined)?.trim() || | |
| `http://${debuggerHost}`), |
🤖 Prompt for AI Agents
In packages/expo/src/index.ts around lines 61-62, the code casts
process.env.EXPO_PUBLIC_SERVER_ORIGIN to string | undefined and uses the nullish
coalescing operator, but that will not fall back if the env var is an empty
string which can break new URL(); change the fallback logic to either use the
logical OR operator (||) so empty strings fall back to http://${debuggerHost},
or add explicit validation that treats "" as missing (e.g., trim and check
length) before constructing the URL; keep the defensive cast but ensure the
selected value is a non-empty valid origin prior to calling new URL().
| "main": "./dist/index.cjs", | ||
| "module": "./dist/index.js", | ||
| "types": "./dist/index.d.ts", | ||
| "module": "./dist/index.mjs", |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
cat -n packages/mime-types/package.json | head -80Repository: pingdotgg/uploadthing
Length of output: 2503
🌐 Web query:
tsdown v0.17.4 changelog breaking changes mjs d.mts
💡 Result:
Do you mean tsdown v0.17.4 (the bundler) or rolldown-plugin-dts / another package? I couldn't find a tsdown v0.17.4 release in the registries — please confirm which package/version you mean and I'll fetch the changelog and check for breaking changes about .mjs / .d.mts.
🏁 Script executed:
sed -n '95,105p' packages/mime-types/package.jsonRepository: pingdotgg/uploadthing
Length of output: 286
🏁 Script executed:
# Search for tsdown in the entire package.json
rg 'tsdown' packages/mime-types/package.json -A 2 -B 2Repository: pingdotgg/uploadthing
Length of output: 450
🌐 Web query:
tsdown egoist bundler npm package versions
💡 Result:
Here are the current npm versions I found:
- tsdown — 0.14.2 (latest). [1]
- egoist — 1.0.2 (latest published). [2]
- bundler — 0.8.0 (latest published). [3]
Sources: npm package pages for each package.
[1] https://www.npmjs.com/package/tsdown
[2] https://www.npmjs.com/package/egoist
[3] https://www.npmjs.com/package/bundler
🌐 Web query:
tsdown npm registry version 0.17.4
💡 Result:
I couldn't find a published npm package version 0.17.4 for tsdown. The npm/registry listings and package-version trackers show versions up to 0.17.0 (and other 0.16/0.15 releases), but no 0.17.4 release. [1][2]
Sources:
- npm package pages for tsdown (versions list). [1]
- Socket / package-versions listing for tsdown (shows latest 0.17.0, no 0.17.4). [2]
Would you like me to watch for 0.17.4 and notify you if it appears, or check the GitHub tags/releases for a pending tag?
🌐 Web query:
site:github.com egoist tsdown releases v0.17.4
💡 Result:
No matching release found. The egoist org hosts "tsup" (migration to "tsdown" is mentioned in tsup README) [1], while "tsdown" is a separate repo under rolldown (its releases page) — there is no "egoist/tsdown v0.17.4" release. [1][2]
Sources:
[1] egoist/tsup README (mentions migration to tsdown).
[2] rolldown/tsdown Releases page.
🌐 Web query:
tsdown github releases tags all versions
💡 Result:
You can view all tsdown releases / tags these ways:
- GitHub Releases page: https://github.com/rolldown/tsdown/releases. [1]
- npm versions listing (all published package versions): https://www.npmjs.com/package/tsdown (click “Versions”). [2]
Command-line options:
- List remote Git tags: git ls-remote --tags https://github.com/rolldown/tsdown.git
- Using GitHub CLI: gh release list --repo rolldown/tsdown
- GitHub API (JSON): curl -s "https://api.github.com/repos/rolldown/tsdown/releases" | jq '.[].tag_name'
Sources: [1], [2].
🏁 Script executed:
#!/bin/bash
# Check tsdown releases from GitHub API
curl -s "https://api.github.com/repos/rolldown/tsdown/releases" | jq -r '.[].tag_name' | head -20Repository: pingdotgg/uploadthing
Length of output: 266
🏁 Script executed:
#!/bin/bash
# Also check git tags
git ls-remote --tags https://github.com/rolldown/tsdown.git | grep -E 'refs/tags/v' | tail -20Repository: pingdotgg/uploadthing
Length of output: 1254
🌐 Web query:
tsdown v0.17.4 release notes changelog mjs d.mts
💡 Result:
I couldn't find a v0.17.4 release for tsdown — the official GitHub Releases list shows v0.17.3 as the latest (v0.17.0–v0.17.3 visible). See the repo releases page. [1]
If you want, I can:
- search the repo tags/commits for any unpublished v0.17.4 changes (or PRs/commits mentioning .mjs / .d.mts), or
- open a specific release/PR/commit to extract changelog details about .mjs / .d.mts support.
Which would you like?
Sources:
[1] rolldown/tsdown — Releases (GitHub).
🏁 Script executed:
#!/bin/bash
# Fetch tsdown v0.17.4 release notes from GitHub
curl -s "https://api.github.com/repos/rolldown/tsdown/releases/tags/v0.17.4" | jq -r '.body'Repository: pingdotgg/uploadthing
Length of output: 1030
🏁 Script executed:
#!/bin/bash
# Check tsdown configuration in the package
find packages/mime-types -name "tsdown*" -o -name ".tsdown*" 2>/dev/nullRepository: pingdotgg/uploadthing
Length of output: 101
🏁 Script executed:
#!/bin/bash
# Check if there's a tsdown config in package.json or root
cat packages/mime-types/package.json | jq '.tsdown' 2>/dev/null || echo "No tsdown config in package.json"Repository: pingdotgg/uploadthing
Length of output: 69
🏁 Script executed:
#!/bin/bash
# Check for tsdown config files in root
ls -la | grep -i tsdownRepository: pingdotgg/uploadthing
Length of output: 47
🏁 Script executed:
cat -n packages/mime-types/tsdown.config.tsRepository: pingdotgg/uploadthing
Length of output: 748
🌐 Web query:
tsdown format esm cjs automatic file extension .mjs .cjs generation
💡 Result:
Short answer: tsdown chooses extensions based on the output format and your package type, but you can force explicit .mjs/.cjs output either by using TypeScript’s .mts/.cts source extensions or by configuring tsdown (format + fixedExtension) — and there are small helper tools (e.g., ts2mjs) if you need post-emit renames/import rewriting.
How to get automatic .mjs / .cjs output
- Use tsdown’s format option to produce ESM and/or CJS outputs: tsdown --format esm or --format cjs (you may pass both). tsdown will select appropriate extensions for each format by default. [1]
- Rely on package.json "type": "module" vs "commonjs": Node’s resolution affects whether .js is treated as ESM or CJS; tsdown will consider package type when deciding extensions (so .js may be used for both depending on package.type). For guaranteed explicit module files use .mjs/.cjs. [3][1]
- Force explicit extensions with TypeScript source extensions: if you name sources .mts (ESM) or .cts (CJS), TypeScript emits .mjs/.cjs respectively — tsdown/TS toolchains follow this behavior. Use .d.mts/.d.cts for declaration files. [3][8]
- tsdown config: you can set per-format options and enable a "fixedExtension" mode (or equivalent in tsdown) so ESM outputs keep .mjs and CJS keep .cjs rather than relying on package.type. Check tsdown’s output/extension settings in the config to force per-format extensions. [2]
- Post-emit rename + import-fix tools: if your toolchain emits .js but you want .mjs/.cjs, use utilities like ts2mjs which rename emitted files and update relative imports/maps/dts names (supports a --cjs flag for .cjs output). [2]
Recommended approaches (pick one)
- Best for clarity: set package.json "type": "module", emit ESM (tsdown --format esm) and/or use .mts sources so outputs are .mjs when you want them explicit. [1][3]
- Best for dual-publishing: build both formats (tsdown --format esm --format cjs) and configure tsdown to emit fixed extensions (.mjs for esm, .cjs for cjs) or let tsdown pick sensible extensions and add package.exports accordingly. [1][2]
- Quick fix if using tsc emit .js: run ts2mjs after emit to rename files and rewrite imports. [2]
Sources
[1] tsdown — Output Format / options (tsdown.dev). (tsdown.dev)
[2] tsdown — Output generation / extension resolution (deepwiki summary of rolldown/tsdown docs). (deepwiki.com)
[3] TypeScript / Node ESM docs — .mts/.cts → .mjs/.cjs behavior. (typescript.p2hp.com)
[4] ts2mjs npm (rename/rewrite .js → .mjs/.cjs). (npmjs.com)
If you want, tell me your current tsdown config / package.json and I’ll give the exact tsdown config or commands to produce .mjs/.cjs outputs.
Citations:
- 1: https://tsdown.dev/options/output-format?utm_source=openai
- 2: https://deepwiki.com/rolldown/tsdown/3.2-output-generation?utm_source=openai
- 3: https://typescript.p2hp.com/docs/handbook/esm-node.html?utm_source=openai
- 4: https://www.npmjs.com/package/ts2mjs?utm_source=openai
🏁 Script executed:
#!/bin/bash
# Check git history for tsdown.config.ts to see recent changes
cd packages/mime-types && git log --oneline -10 -- tsdown.config.ts 2>/dev/null || echo "No git history available"Repository: pingdotgg/uploadthing
Length of output: 77
🏁 Script executed:
#!/bin/bash
# Check git diff for recent changes to tsdown.config.ts
cd packages/mime-types && git diff HEAD~5 -- tsdown.config.ts 2>/dev/null || echo "Cannot show diff"Repository: pingdotgg/uploadthing
Length of output: 81
🏁 Script executed:
#!/bin/bash
# Check source file extensions
ls -la packages/mime-types/src/Repository: pingdotgg/uploadthing
Length of output: 595
🏁 Script executed:
#!/bin/bash
# Check build script and any post-processing
grep -A 5 '"build"' packages/mime-types/package.jsonRepository: pingdotgg/uploadthing
Length of output: 271
🏁 Script executed:
#!/bin/bash
# Look for any dist directory or build output to see what extensions are actually generated
find packages/mime-types -name "*.mjs" -o -name "*.d.mts" 2>/dev/null | head -20Repository: pingdotgg/uploadthing
Length of output: 47
🌐 Web query:
tsdown v0.17.4 documentation output file extensions esm cjs behavior
💡 Result:
Short answer — in tsdown (v0.17.x) the default output format is ESM and tsdown picks file extensions intelligently:
- Default format: esm (ESM output). [1]
- ESM output commonly emits .mjs (but tsdown can emit .js for ESM depending on package config/consumer expectations — the docs show examples producing dist/index.mjs by default). [1][3]
- CJS output emits .cjs (or .js in some package/type configurations). [1][2]
- You can build multiple formats in one run (e.g., --format esm --format cjs) and tsdown will emit both outputs. [1]
- There is an extension-resolution behavior (and a fixedExtension mode) that controls whether ESM uses .mjs and CJS uses .cjs vs .js; this logic is documented in the output-generation/extension section. [2]
Sources: tsdown Output Format and Getting Started docs, and an output-generation summary. [1][3][2]
References
[1] tsdown — Output Format docs.
[2] tsdown output-generation / extension-resolution summary (deepwiki).
[3] tsdown — Getting Started example showing dist/index.mjs.
🌐 Web query:
tsdown changelog v0.17.0 to v0.17.4 file extension output changes
💡 Result:
Short answer: Between v0.17.0 and the v0.17.x patch releases, tsdown did not secretly switch all output extensions — instead it exposed/clarified controls for output file extensions:
- By default tsdown chooses output extensions based on package type (so .js/.mjs/.cjs vary with format + package type). [1][3]
- You can force a fixed extension via fixedExtension (forces .mjs for ESM / .cjs for CJS). [2]
- You can also override per-output extensions with outExtensions / outExtensions factory for custom extension rules (which overrides fixedExtension). [2]
- A recent patch (v0.17.3) merged input & output options and improved per-format hook/option behavior, which affects how format-specific extension rules are applied. [1]
Sources:
- tsdown releases (v0.17.0 → v0.17.3 release notes). [1]
- tsdown Options / Interface (fixedExtension, outExtensions). [2]
- tsdown Output Format / extension behavior. [3]
Add fixedExtension: true to tsdown.config.ts to ensure ESM files are generated as .mjs and declaration files as .d.mts.
The package.json exports declare .mjs and .d.mts file paths (lines 13, 19–20, 29–30, 39–40, 49–50, 59–60, 69–70), but tsdown.config.ts does not configure fixedExtension to force these extensions. Without this setting, tsdown may generate .js files instead, causing module resolution failures. Update the config:
export default defineConfig({
// ... existing config ...
fixedExtension: true,
// ... rest of config ...
});Note: v0.17.3 merged input/output options which affects extension behavior, so this setting is essential for the current version.
🤖 Prompt for AI Agents
In packages/mime-types/package.json around line 13 (and other export lines
referencing .mjs/.d.mts), the build config may emit .js/.d.ts instead of the
.mjs/.d.mts paths declared; open tsdown.config.ts and add fixedExtension: true
to the exported defineConfig object (top-level config) so tsdown forces .mjs for
ESM outputs and .d.mts for declarations, then rebuild to ensure generated file
extensions match package.json exports.
| "module": "./dist/index.js", | ||
| "types": "./dist/index.d.ts", | ||
| "module": "./dist/index.mjs", | ||
| "types": "./dist/index.d.cts", |
There was a problem hiding this comment.
The types field should point to ESM types, not CommonJS types.
Line 14 sets types to ./dist/index.d.cts (CommonJS), but the package is ESM-first ("type": "module") and exports ESM as the default. The top-level types field serves as a fallback for TypeScript resolution when condition-specific types aren't matched. For this ESM-first package, it should point to ./dist/index.d.mts to maintain consistency with the import export condition on line 19.
- "types": "./dist/index.d.cts",
+ "types": "./dist/index.d.mts",📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| "types": "./dist/index.d.cts", | |
| "types": "./dist/index.d.mts", |
🤖 Prompt for AI Agents
In packages/mime-types/package.json around line 14, the "types" field currently
points to ./dist/index.d.cts (CommonJS) but the package is ESM-first; change the
"types" entry to ./dist/index.d.mts so top-level TypeScript resolution uses the
ESM declaration, and make sure the corresponding ./dist/index.d.mts file is
generated by the build (or rename/copy existing .d.cts to .d.mts) so the path is
valid.
| "vitest": "3.2.4", | ||
| "tsdown": "0.17.4", | ||
| "typescript": "5.9.3", | ||
| "vitest": "4.0.15", |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
vitest v4.0 breaking changes migration guide from v3
💡 Result:
Here are the main breaking changes and migration steps when upgrading Vitest v3 → v4 (summary of the official migration guide and release notes):
Key breaking changes
- V8 coverage provider changed (new AST-based remapping) — expect different coverage output. [1][2]
- Browser provider API: providers now accept an object (not a string) and Playwright factory property names changed to align with Playwright. Update browser config accordingly. [1][2]
- Removed/deprecated APIs/options (use replacements):
- removed reporters: 'basic' (use reporters: [['default',{ summary:false }]]). [1]
- removed deprecated config options: poolMatchGlobs, environmentMatchGlobs → use projects. [1]
- moved deps.* options into server.deps.* (deps.external / deps.inline / deps.fallbackCJS → server.deps.*). [1]
- removed browser.testerScripts → use browser.testerHtmlPath. [1]
- removed minWorkers (only maxWorkers remains). [1]
- removed several deprecated reporter hooks (onCollected, onSpecsCollected, onPathsCollected, onTaskUpdate, onFinished) — see new Reporters API. [1]
- vitest no longer injects __vitest_executor; uses moduleRunner; vitest/execute entry point removed. [1]
- vite-node is no longer a dependency; deps.optimizer.web renamed to deps.optimizer.client (or custom names). [1]
- Deprecated types removed (fixes accidental @types/node pull-in). [1]
Migration checklist (practical steps)
- Read the Migration Guide and changelog, then pin a v4 tag in CI. [1][2]
- Update configs:
- Replace any reporters: 'basic' usage.
- Move any deps.* settings into server.deps.*.
- Replace poolMatchGlobs/environmentMatchGlobs with projects.
- Update browser config to the new object-based provider format. [1]
- Update custom environments/reporters:
- Replace transformMode → viteEnvironment or rely on server.environments.
- Remove reliance on vitest/execute and __vitest_executor. Use ModuleRunner APIs if needed. [1]
- Audit usage of removed reporter hooks and deprecated APIs; migrate to the new Reporters API. [1]
- Re-run tests and review coverage reports (coverage may change due to new remapping). Adjust thresholds if needed. [1][2]
- Update any integrations or packages that assumed vite-node as a dependency or old optimizer naming. [1]
Sources
- Vitest Migration Guide (Migrating to 4.0). [1]
- Vitest 4.0 release post / changelog. [2]
If you want, I can:
- show exact config diffs for your vitest.config (paste it here), or
- fetch the full list of removed/deprecated config keys and reporter API replacements from the docs.
Verify vitest v4 breaking changes and test compatibility.
Lines 54 and 60 show major version upgrades: @vitest/coverage-istanbul: 3.2.4 → 4.0.15 and vitest: 4.0.15. Vitest v4 includes breaking changes:
- V8 coverage provider now uses AST-based remapping — coverage output will differ; ensure coverage-istanbul aligns with this change
- Multiple config options removed/moved (e.g.,
deps.*→server.deps.*) - Reporter API and module execution changes
Confirm the test suite passes with v4, coverage thresholds are still valid, and any necessary config updates are applied.
There was a problem hiding this comment.
Actionable comments posted: 3
🧹 Nitpick comments (1)
examples/minimal-expo/app.config.ts (1)
19-22: Redundant light/dark icon configuration.Both variants point to the same
./assets/icon.png. If distinct appearance modes aren't needed, you can simplify by using justicon: "./assets/icon.png"at theioslevel (similar to the top-levelicon), or provide different assets if dark mode differentiation is intended.
📜 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 (24)
examples/minimal-expo/app.config.ts(1 hunks)examples/minimal-expo/tsconfig.json(1 hunks)examples/minimal-solidstart/package.json(1 hunks)examples/minimal-solidstart/postcss.config.js(1 hunks)examples/minimal-solidstart/src/main.css(1 hunks)examples/minimal-solidstart/src/routes/api/uploadthing.ts(1 hunks)examples/minimal-solidstart/tailwind.config.ts(0 hunks)examples/with-tailwindcss/.env.example(0 hunks)examples/with-tailwindcss/CHANGELOG.md(0 hunks)examples/with-tailwindcss/README.md(0 hunks)examples/with-tailwindcss/next-env.d.ts(0 hunks)examples/with-tailwindcss/next.config.js(0 hunks)examples/with-tailwindcss/package.json(0 hunks)examples/with-tailwindcss/postcss.config.js(0 hunks)examples/with-tailwindcss/src/app/api/uploadthing/route.ts(0 hunks)examples/with-tailwindcss/src/app/globals.css(0 hunks)examples/with-tailwindcss/src/app/layout.tsx(0 hunks)examples/with-tailwindcss/src/app/page.tsx(0 hunks)examples/with-tailwindcss/src/server/uploadthing.ts(0 hunks)examples/with-tailwindcss/src/utils/uploadthing.ts(0 hunks)examples/with-tailwindcss/tailwind.config.ts(0 hunks)examples/with-tailwindcss/tsconfig.json(0 hunks)package.json(2 hunks)pnpm-workspace.yaml(1 hunks)
💤 Files with no reviewable changes (16)
- examples/with-tailwindcss/README.md
- examples/with-tailwindcss/postcss.config.js
- examples/with-tailwindcss/.env.example
- examples/with-tailwindcss/src/utils/uploadthing.ts
- examples/with-tailwindcss/tsconfig.json
- examples/with-tailwindcss/src/app/globals.css
- examples/with-tailwindcss/src/app/page.tsx
- examples/with-tailwindcss/src/app/api/uploadthing/route.ts
- examples/with-tailwindcss/src/server/uploadthing.ts
- examples/with-tailwindcss/tailwind.config.ts
- examples/with-tailwindcss/src/app/layout.tsx
- examples/with-tailwindcss/next-env.d.ts
- examples/minimal-solidstart/tailwind.config.ts
- examples/with-tailwindcss/next.config.js
- examples/with-tailwindcss/CHANGELOG.md
- examples/with-tailwindcss/package.json
🚧 Files skipped from review as they are similar to previous changes (3)
- examples/minimal-solidstart/package.json
- package.json
- pnpm-workspace.yaml
🧰 Additional context used
🧠 Learnings (3)
📚 Learning: 2024-11-11T19:59:56.512Z
Learnt from: markflorkowski
Repo: pingdotgg/uploadthing PR: 1046
File: playground-v6/app/layout.tsx:21-21
Timestamp: 2024-11-11T19:59:56.512Z
Learning: In the `playground-v6` project, using the Tailwind CSS CDN in `playground-v6/app/layout.tsx` is acceptable as it is a playground for testing purposes and not intended for production deployment.
Applied to files:
examples/minimal-solidstart/postcss.config.jsexamples/minimal-solidstart/src/main.css
📚 Learning: 2024-10-08T16:10:15.532Z
Learnt from: markflorkowski
Repo: pingdotgg/uploadthing PR: 978
File: examples/minimal-appdir/src/server/uploadthing.ts:62-62
Timestamp: 2024-10-08T16:10:15.532Z
Learning: In the `onUploadComplete` handler in `examples/minimal-appdir/src/server/uploadthing.ts`, the return value `{ foo: "bar" }` is intentionally a placeholder for user-defined logic and may represent database returns or other computed values.
Applied to files:
examples/minimal-solidstart/src/routes/api/uploadthing.ts
📚 Learning: 2024-10-08T16:10:15.532Z
Learnt from: markflorkowski
Repo: pingdotgg/uploadthing PR: 978
File: examples/minimal-appdir/src/server/uploadthing.ts:41-43
Timestamp: 2024-10-08T16:10:15.532Z
Learning: In the `examples/minimal-appdir/src/server/uploadthing.ts` and other example files, the commented-out header validation code is intentional and serves as an example for users.
Applied to files:
examples/minimal-solidstart/src/routes/api/uploadthing.ts
⏰ 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: bundle-analyze-result
- GitHub Check: lint
- GitHub Check: typecheck
- GitHub Check: build
- GitHub Check: build
🔇 Additional comments (6)
examples/minimal-expo/tsconfig.json (1)
7-9: Multi-line formatting improves readability.The reformatting of the path alias mapping from a single-line to multi-line format is a good improvement for git diffs and code readability. This aligns with the PR's maintenance goals.
examples/minimal-solidstart/src/main.css (1)
1-3: Tailwind v4@sourcepath is correctly formatted; verify standard workspace layout.The
@source "../node_modules/@uploadthing/solid/dist";directive is the documented approach for Tailwind v4—relative paths are the only supported form (package specifiers like@source "@uploadthing/solid/dist"are not supported). This will work correctly ifnode_modulesis hoisted at the repository root, which is standard in monorepos. One caveat: if a.gitignorefile exists inside the target directory (@uploadthing/solid/dist), Tailwind may skip those files during scanning—ensure the directory is not inadvertently excluded by.gitignore.examples/minimal-solidstart/src/routes/api/uploadthing.ts (1)
9-14: The code is correct foruploadthing/[email protected]. Theconfig.tokenoption withprocess.env.UPLOADTHING_TOKENmatches the documented API and is the intended pattern. If the token is undefined at runtime, that's an environment setup issue (missing.envor deployment configuration), not a code issue—UploadThing will handle the error appropriately. No changes needed.Likely an incorrect or invalid review comment.
examples/minimal-expo/app.config.ts (3)
7-14: LGTM!Good modernization choices:
userInterfaceStyle: "automatic"follows system preferences for better UX, andnewArchEnabled: trueis appropriate given React Native 0.81.5's stable new architecture support.
24-30: LGTM!Placeholder bundle identifiers are appropriate for a minimal example template, and
edgeToEdgeEnabled: trueis a good addition for modern Android UI.
43-43: LGTM!The
expo-routerplugin is correctly configured.
| experiments: { | ||
| tsconfigPaths: true, | ||
| typedRoutes: true, | ||
| reactCanary: true, | ||
| reactCompiler: true, | ||
| }, |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Check package.json for versions
echo "=== Expo and React versions ==="
cat examples/minimal-expo/package.json | grep -E '"expo"|"react"|"react-native"' | head -20
echo ""
echo "=== Checking for babel config ==="
fd -t f 'babel' examples/minimal-expo
echo ""
echo "=== Full package.json for context ==="
cat examples/minimal-expo/package.jsonRepository: pingdotgg/uploadthing
Length of output: 1978
🏁 Script executed:
cat examples/minimal-expo/babel.config.jsRepository: pingdotgg/uploadthing
Length of output: 237
Add React Compiler Babel plugin to support reactCompiler experiment.
The reactCompiler flag in experiments requires the babel-plugin-react-compiler Babel plugin to actually compile. The current babel.config.js only includes react-native-reanimated/plugin and is missing the React Compiler plugin configuration. Without it, the reactCompiler flag will have no effect. Add the plugin to babel.config.js:
plugins: [
"babel-plugin-react-compiler",
"react-native-reanimated/plugin"
]The other flags (tsconfigPaths, typedRoutes, reactCanary) are compatible with Expo 54 and React 19.1.4.
🤖 Prompt for AI Agents
In examples/minimal-expo/app.config.ts around lines 37 to 42, the experiments
enable reactCompiler but the project’s Babel config doesn’t include the required
babel-plugin-react-compiler, so the reactCompiler flag is ineffective; update
babel.config.js to add "babel-plugin-react-compiler" to the plugins array
(ensuring it is included before/react-native-reanimated/plugin if order
matters), then verify Babel config loads and rebuilds to confirm the React
Compiler is applied.
| plugins: { | ||
| tailwindcss: {}, | ||
| autoprefixer: {}, | ||
| "@tailwindcss/postcss": {}, |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Verify Tailwind CSS v4 migration in examples/minimal-solidstart
echo "=== Checking package.json for @tailwindcss/postcss dependency ==="
if [ -f "examples/minimal-solidstart/package.json" ]; then
cat "examples/minimal-solidstart/package.json" | jq '.dependencies["@tailwindcss/postcss"], .devDependencies["@tailwindcss/postcss"]' 2>/dev/null || cat "examples/minimal-solidstart/package.json"
else
echo "package.json not found"
fi
echo -e "\n=== Checking for CSS files with @tailwind directives ==="
if [ -d "examples/minimal-solidstart" ]; then
find "examples/minimal-solidstart" -type f \( -name "*.css" -o -name "*.scss" -o -name "*.tsx" -o -name "*.jsx" \) -exec grep -l "@tailwind" {} \;
else
echo "Directory not found"
fi
echo -e "\n=== Checking for CSS files with @import tailwindcss syntax ==="
if [ -d "examples/minimal-solidstart" ]; then
find "examples/minimal-solidstart" -type f \( -name "*.css" -o -name "*.scss" \) -exec grep -l "@import.*tailwindcss" {} \;
else
echo "Directory not found"
fi
echo -e "\n=== Checking tailwind config file ==="
if [ -f "examples/minimal-solidstart/tailwind.config.js" ]; then
cat "examples/minimal-solidstart/tailwind.config.js"
else
echo "tailwind.config.js not found or not present (using defaults)"
fi
echo -e "\n=== Listing CSS files in project ==="
find "examples/minimal-solidstart" -type f \( -name "*.css" -o -name "*.scss" \) 2>/dev/null | head -20Repository: pingdotgg/uploadthing
Length of output: 482
🏁 Script executed:
#!/bin/bash
echo "=== Contents of main.css ==="
cat "examples/minimal-solidstart/src/main.css"
echo -e "\n=== Full package.json content ==="
cat "examples/minimal-solidstart/package.json"Repository: pingdotgg/uploadthing
Length of output: 883
🌐 Web query:
Tailwind CSS v4 PostCSS plugin configuration postcss.config.js
💡 Result:
Use the new PostCSS plugin package @tailwindcss/postcss (Tailwind v4 separated the PostCSS plugin from the main package). Minimal recommended config:
-
ESM (preferred): create postcss.config.mjs
export default {
plugins: {
"@tailwindcss/postcss": {},
},
} -
CJS (if your toolchain requires CommonJS): create postcss.config.cjs or postcss.config.js
module.exports = {
plugins: [
require("@tailwindcss/postcss"),
],
}
Also:
- Install packages: npm install tailwindcss @tailwindcss/postcss postcss.
- You no longer use tailwindcss directly as the PostCSS plugin; import Tailwind in your entry CSS (e.g. @import "tailwindcss";). (tailwindcss.com)
If you want, tell me your build tool (Vite, Webpack, Next, etc.) and I’ll give the exact file name and example for that setup.
Citations:
Add missing @tailwindcss/postcss dependency to package.json.
The PostCSS configuration correctly references the @tailwindcss/postcss plugin for Tailwind CSS v4, and the CSS file properly uses the new @import "tailwindcss" syntax. However, the @tailwindcss/postcss package is not listed in package.json dependencies or devDependencies. This package must be installed as it's a separate dependency from the main tailwindcss package in v4.
Add @tailwindcss/postcss to devDependencies alongside the existing tailwindcss and postcss entries.
🤖 Prompt for AI Agents
In examples/minimal-solidstart/postcss.config.js around line 3 the PostCSS
config references the @tailwindcss/postcss plugin but that package is missing
from package.json; open package.json and add @tailwindcss/postcss to
devDependencies (next to tailwindcss and postcss) and then run your package
manager (npm/yarn/pnpm) to install it so the PostCSS config resolves
successfully.
| console.log(process.env.UPLOADTHING_TOKEN); | ||
|
|
There was a problem hiding this comment.
Do not log UPLOADTHING_TOKEN (secret leakage).
This prints the raw token to logs (CI/prod/dev), which is a credential disclosure risk.
-console.log(process.env.UPLOADTHING_TOKEN);
+// Avoid logging secrets; if you need a sanity check, log presence only:
+// console.log("UPLOADTHING_TOKEN set:", Boolean(process.env.UPLOADTHING_TOKEN));📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| console.log(process.env.UPLOADTHING_TOKEN); | |
| // Avoid logging secrets; if you need a sanity check, log presence only: | |
| // console.log("UPLOADTHING_TOKEN set:", Boolean(process.env.UPLOADTHING_TOKEN)); | |
🤖 Prompt for AI Agents
In examples/minimal-solidstart/src/routes/api/uploadthing.ts around lines 7-8,
remove the console.log that prints process.env.UPLOADTHING_TOKEN to avoid
leaking a secret; instead, delete the log statement or replace it with a
non-sensitive debug message (e.g., log that the token exists or use a boolean
check) and, if needed, use secure secret-checking utilities or environment
validation that do not output the token value.
There was a problem hiding this comment.
Actionable comments posted: 2
♻️ Duplicate comments (2)
packages/uploadthing/package.json (1)
177-177: Move@vitest/browser-playwrighttodevDependencies— test tool misplaced.
@vitest/browser-playwrightis a testing/build tool and should never be independencies. This will be unnecessarily bundled and shipped in production, increasing package size and creating false transitive dependencies.Apply this diff:
"dependencies": { "@effect/platform": "0.93.8", "@standard-schema/spec": "1.0.0-beta.4", "@uploadthing/mime-types": "workspace:*", "@uploadthing/shared": "workspace:*", - "@vitest/browser-playwright": "^4.0.15", "effect": "3.19.12" }, "devDependencies": { "@effect/vitest": "0.27.0", + "@vitest/browser-playwright": "^4.0.15", "@remix-run/server-runtime": "^2.17.2",packages/react/package.json (1)
78-78: Move build/test tools fromdependenciestodevDependencies.
@tailwindcss/cliand@vitest/browser-playwrightare build-time and test-time tools respectively. They should not be in productiondependencies, as consumers will unnecessarily install tooling they don't need.Run the following script to confirm these packages are not used at runtime:
#!/bin/bash # Check for runtime imports of these packages in source code echo "=== Checking for @tailwindcss/cli runtime usage ===" rg "@tailwindcss/cli" packages/react/src --type ts --type tsx --type js --type jsx 2>/dev/null || echo "✓ No runtime imports found" echo -e "\n=== Checking for @vitest/browser-playwright runtime usage ===" rg "@vitest/browser-playwright" packages/react/src --type ts --type tsx --type js --type jsx 2>/dev/null || echo "✓ No runtime imports found" echo -e "\n=== Checking build scripts ===" cat packages/react/package.json | jq '.scripts'If neither package is used at runtime, apply this diff:
"dependencies": { "@tailwindcss/cli": "^4.1.18", "@uploadthing/shared": "workspace:*", - "@vitest/browser-playwright": "^4.0.15", "file-selector": "0.6.0" },Then move both to
devDependencies.Also applies to: 80-80
📜 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 (14)
examples/backend-adapters/server/package.json(1 hunks)examples/backend-adapters/server/src/cf-worker.ts(1 hunks)examples/backend-adapters/server/src/custom.ts(2 hunks)examples/backend-adapters/server/src/effect-platform.ts(1 hunks)examples/backend-adapters/server/src/elysia.ts(1 hunks)examples/backend-adapters/server/src/express.ts(1 hunks)examples/backend-adapters/server/src/fastify.ts(1 hunks)examples/backend-adapters/server/src/h3.ts(1 hunks)examples/backend-adapters/server/src/hono.ts(1 hunks)examples/backend-adapters/server/tsconfig.json(1 hunks)packages/react/package.json(4 hunks)packages/react/turbo.json(1 hunks)packages/uploadthing/package.json(12 hunks)packages/uploadthing/turbo.json(1 hunks)
✅ Files skipped from review due to trivial changes (1)
- examples/backend-adapters/server/src/elysia.ts
🧰 Additional context used
🧠 Learnings (8)
📚 Learning: 2024-10-08T16:10:15.532Z
Learnt from: markflorkowski
Repo: pingdotgg/uploadthing PR: 978
File: examples/minimal-appdir/src/server/uploadthing.ts:62-62
Timestamp: 2024-10-08T16:10:15.532Z
Learning: In the `onUploadComplete` handler in `examples/minimal-appdir/src/server/uploadthing.ts`, the return value `{ foo: "bar" }` is intentionally a placeholder for user-defined logic and may represent database returns or other computed values.
Applied to files:
examples/backend-adapters/server/src/cf-worker.tsexamples/backend-adapters/server/src/effect-platform.tsexamples/backend-adapters/server/src/custom.tsexamples/backend-adapters/server/src/fastify.tsexamples/backend-adapters/server/src/h3.tsexamples/backend-adapters/server/src/hono.tsexamples/backend-adapters/server/src/express.ts
📚 Learning: 2024-10-08T16:10:15.532Z
Learnt from: juliusmarminge
Repo: pingdotgg/uploadthing PR: 980
File: packages/solid/src/create-uploadthing.ts:119-119
Timestamp: 2024-10-08T16:10:15.532Z
Learning: In this codebase, the naming conventions differ between frameworks to align with ecosystem practices:
- In React and Vue, functions are prefixed with `useX` (e.g., `useRouteConfig`) to match built-in hooks and conventions.
- In Solid and Svelte, functions are prefixed with `createX` (e.g., `createRouteConfig`) to align with their respective built-in functions and ecosystem conventions.
Applied to files:
packages/uploadthing/turbo.jsonexamples/backend-adapters/server/src/h3.tspackages/uploadthing/package.json
📚 Learning: 2024-10-08T16:10:15.532Z
Learnt from: markflorkowski
Repo: pingdotgg/uploadthing PR: 978
File: examples/minimal-appdir/src/server/uploadthing.ts:41-43
Timestamp: 2024-10-08T16:10:15.532Z
Learning: In the `examples/minimal-appdir/src/server/uploadthing.ts` and other example files, the commented-out header validation code is intentional and serves as an example for users.
Applied to files:
examples/backend-adapters/server/src/h3.tsexamples/backend-adapters/server/src/express.ts
📚 Learning: 2024-11-05T17:11:33.300Z
Learnt from: juliusmarminge
Repo: pingdotgg/uploadthing PR: 1013
File: packages/mime-types/package.json:24-69
Timestamp: 2024-11-05T17:11:33.300Z
Learning: In this codebase, the bundler `bunchee` uses `package.json` as the source of truth for exports and outputs matching files during the build process. Therefore, the export paths specified in `package.json` align with the generated build output, even if the source files are located in a `src/` directory.
Applied to files:
packages/react/turbo.jsonpackages/react/package.jsonpackages/uploadthing/package.json
📚 Learning: 2024-12-07T18:44:24.444Z
Learnt from: juliusmarminge
Repo: pingdotgg/uploadthing PR: 1090
File: docs/src/components/Code.tsx:135-137
Timestamp: 2024-12-07T18:44:24.444Z
Learning: In `docs/src/components/Code.tsx`, using type casts like `as any` is acceptable due to type mismatches between React 18 and 19. These casts will be addressed when the project upgrades to React 19.
Applied to files:
packages/react/package.json
📚 Learning: 2025-01-24T01:57:53.903Z
Learnt from: markflorkowski
Repo: pingdotgg/uploadthing PR: 1138
File: playground/package.json:27-27
Timestamp: 2025-01-24T01:57:53.903Z
Learning: When reviewing package versions, verify the latest version from the npm registry instead of making assumptions about version availability. Package versions can change frequently, and cached knowledge about versions can become outdated quickly.
Applied to files:
packages/react/package.json
📚 Learning: 2024-11-11T19:59:56.512Z
Learnt from: markflorkowski
Repo: pingdotgg/uploadthing PR: 1046
File: playground-v6/app/layout.tsx:21-21
Timestamp: 2024-11-11T19:59:56.512Z
Learning: In the `playground-v6` project, using the Tailwind CSS CDN in `playground-v6/app/layout.tsx` is acceptable as it is a playground for testing purposes and not intended for production deployment.
Applied to files:
packages/react/package.json
📚 Learning: 2024-11-07T18:28:14.191Z
Learnt from: juliusmarminge
Repo: pingdotgg/uploadthing PR: 1046
File: playground/package.json:26-26
Timestamp: 2024-11-07T18:28:14.191Z
Learning: In `package.json`, the `typescript-eslint` package is correctly used and should not be replaced with `typescript-eslint/eslint-plugin` and `typescript-eslint/parser` in modern configurations.
Applied to files:
packages/uploadthing/package.json
🧬 Code graph analysis (1)
examples/backend-adapters/server/src/custom.ts (1)
packages/uploadthing/src/_internal/handler.ts (1)
makeAdapterHandler(66-101)
🪛 GitHub Actions: Examples E2E
examples/backend-adapters/server/src/custom.ts
[error] 42-42: TS2322: Type 'Effect<BunRequest, never, never>' is not assignable to type 'Effect<Request<unknown, CfProperties>, never, never>'.
⏰ 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: typecheck
- GitHub Check: build
🔇 Additional comments (19)
packages/uploadthing/turbo.json (1)
16-16: Output path addition aligns with new React Router export.The addition of
"react-router/**"correctly exposes the build output directory for the newly added./react-routerexport path, enabling Turbo to properly cache and track this output.packages/react/turbo.json (1)
6-11: Output array reformatted and TanStack SSR plugin path added.The addition of
"tanstack-ssr-plugin/**"correctly tracks the new server-side rendering plugin output, maintaining consistency with the existingnext-ssr-plugin/**entry. The multi-line formatting improves clarity.packages/uploadthing/package.json (4)
119-128: React Router export path properly configured.The new
./react-routerexport path correctly mirrors the structure of existing export paths (client, server, remix, etc.) with proper import/require variants and corresponding.d.mts/.mjs/.d.cts/.cjsoutputs.Verify that the
packages/uploadthing/src/react-router.tssource module exists and exports the expected public API.
19-20: Export paths migrated to ESM-first (.mts/.mjs) — verify imports resolve correctly.All export paths have been updated from
.d.ts/.jsto.d.mts/.mjs(with.d.cts/.cjsfallbacks), signaling a shift to ESM-primary build output. This is consistent with modern Node.js and bundler conventions.Ensure:
- The tsdown build configuration generates
.mts/.mjsoutputs (not just.d.ts/.js).- Type checker resolves types correctly via the new
.d.mtspaths.- CommonJS consumers can still require via
.cjsfallbacks without issues.You may want to verify the tsdown config and ensure the build produces the expected file extensions for a subset of export paths.
Also applies to: 29-30, 39-40, 49-50, 59-60, 69-70, 80-81, 91-92, 101-102, 111-112, 131-132, 140-141
154-154: React Router directory added tofilesarray — ensures npm package includes generated outputs.The addition of
"react-router"to thefilesarray ensures that the generatedreact-router/directory (created by tsdown) is included when the package is published to npm, preventing missing exports for downstream consumers.
173-207: Multiple dependency version bumps — verify ecosystem compatibility, especially Tailwind CSS v4 and Next.js 15.Significant version updates include:
- tailwindcss v4.1.18 — Major release with breaking changes: opacity utilities removed (use slash syntax
/), important modifier placement changed (now suffix!), CSS variable syntax updated (parentheses instead of brackets).- typescript 5.9.3 — Recent major version; verify language features align with your codebase.
- next 15.5.9 — v15 includes breaking changes: async Request APIs, changed caching defaults, requires React 19.
- vitest 4.0.15 — v4 release; verify test suite compatibility.
- effect / @effect/platform — Updated to 3.19.12 and 0.93.8 respectively; verify any API changes don't break existing usage.
Before merge, please verify:
- Any Tailwind CSS utilities in the codebase have been updated to match v4 syntax (e.g.,
bg-blue-500/20instead ofbg-opacity-20).- Next.js middleware/app router code is compatible with v15 breaking changes (async cookies/headers, route handler caching defaults).
- Vitest test suite runs successfully with v4.
- Effect library imports and Effect platform APIs still work as expected.
If this package doesn't directly use these libraries (only provides integrations), you may skip this, but double-check the next and tw exports.
examples/backend-adapters/server/tsconfig.json (1)
10-10: TypeScript version compatibility confirmed—no action needed.Lines 10–11 use
erasableSyntaxOnlyandverbatimModuleSyntax, which require TypeScript 5.8+. The project uses TypeScript 5.9.3, which fully supports these compiler options.Also applies to: 11-11
packages/react/package.json (2)
48-56: Verify that source files exist for the newtanstack-ssr-pluginexport.The new export entry is correctly formatted, but confirm that the source file/directory exists and will be built by
tsdown.
84-84: Reconsider the React peer dependency setting.The peer dependency on line 84 is set to
"*", which allows any React version including those incompatible with this package (e.g., React 15 or 16.0–16.7 before hooks were introduced). Since the code uses React hooks extensively, this could cause silent runtime failures for users with unsupported versions.Either use a restrictive semver range like
"^16.8.0"or"^17.0.0", or add runtime validation to provide clear error messages to users with incompatible React versions.examples/backend-adapters/server/src/custom.ts (2)
9-10: Type specificity improvements look reasonable, but contribute to downstream type error.The addition of generic parameters to
BunRequest<string>andServer<unknown>improves type specificity. However, this causes a critical type mismatch at line 42 (see separate comment).
37-40: Generic parameters correctly specified.The explicit generic parameters align with the updated
AdapterArgstype and themakeAdapterHandlersignature.examples/backend-adapters/server/src/effect-platform.ts (1)
16-16: LGTM: Explicit TypeScript extension improves ESM compatibility.The import path change to "./router.ts" aligns with ESM best practices and is consistent with updates across all other adapter files in this PR.
examples/backend-adapters/server/src/cf-worker.ts (1)
5-5: LGTM: Consistent import path update.The explicit ".ts" extension aligns with the ESM module resolution improvements applied across all backend adapters.
examples/backend-adapters/server/src/fastify.ts (1)
6-6: LGTM: Environment loading modernized and import path aligned with ESM standards.The removal of
dotenv/configpaired with the package.json script update to usenode --env-file .env --watchleverages Node's native environment file loading. The explicit ".ts" extension improves module resolution consistency.examples/backend-adapters/server/src/hono.ts (1)
8-8: LGTM: Consistent refactoring with other adapters.Both the environment loading strategy (now using
node --env-file) and the explicit import extension align with the standardization applied across all backend adapters.examples/backend-adapters/server/src/express.ts (1)
6-6: LGTM: Environment and module resolution improvements.The changes align with the repository-wide standardization: native Node.js environment file loading and explicit TypeScript extensions for ESM compatibility.
examples/backend-adapters/server/src/h3.ts (1)
10-10: LGTM: Consistent module resolution update.The explicit ".ts" extension matches the standardization applied across all backend adapters, ensuring consistent ESM module resolution behavior.
examples/backend-adapters/server/package.json (2)
9-11: LGTM: Scripts updated to use Node's native environment file loading.The migration from
tsx watchtonode --env-file .env --watchaligns with the removal ofdotenv/configimports from the source files, leveraging Node.js's built-in environment file support for cleaner dependency management.Also applies to: 13-13
16-17: Dependency updates are compatible with current codebase.The breaking changes introduced in these dependency updates (Wrangler 3→4, Effect 3.17→3.19, TypeScript 5.8→5.9, Express 5.0→5.2) do not affect this codebase:
- No ShardManager or deprecated Effect cluster imports used
- No dynamic wildcard imports affected by esbuild upgrade
- wrangler.toml already uses new format (main field, nodejs_compat)
- Express setup is straightforward with no deprecated patterns
juliusmarminge
force-pushed
the
bump-deps
branch
from
b6d406c to
95b59f8
Compare
need to get this repo pleasant to work in again...
Summary by CodeRabbit
New Features
Dependencies Updated
Examples Removed / Simplified
Bug Fixes & Improvements
Chores
✏️ Tip: You can customize this high-level summary in your review settings.