Next 15 + React 19

[ahkhanjani]

No description provided.

[jpainam]

Thanks for the migration.

i'm was able to pn build, pn lint and pn typecheck locally, but when i open localhost:3000, i get a lot of module not found errors

Module not found: Can't resolve @acme/ui/button

for every single import from packages.

Anything i'm missing out?

alias pn=pnpm

[ahkhanjani]

i'm was able to pn build, pn lint and pn typecheck locally, but when i open localhost:3000, i get a lot of module not found errors

Should've been fixed. I'll look into it

[ahkhanjani]

@jpainam Works fine for me. Make sure you've updated the exports field in packages/ui/package.json. Turpopack doesn't work with wildcard **/* exports.

[jpainam]

@jpainam Works fine for me. Make sure you've updated the exports field in packages/ui/package.json. Turpopack doesn't work with wildcard **/* exports.

That was the issue. Had to export each file individually

[juliusmarminge]

@jpainam Works fine for me. Make sure you've updated the exports field in packages/ui/package.json. Turpopack doesn't work with wildcard **/* exports.

Is that a bug or intended behavior ?

[ahkhanjani]

Is that a bug or intended behavior ?

I couldn't find anything mentioning this directly. There is this indirect mention. I think they simply don't support it.

[juliusmarminge]

That's for turborepo though, I'm guessing the limitation you're pointing at is about turbopack?

Either way I'm fine with explicit exports just thought if we should file an issue to turbopack since afaik everything that works with webpack should work in turbopack too

[ahkhanjani]

I'm guessing the limitation you're pointing at is about turbopack?

Yes

Either way I'm fine with explicit exports just thought if we should file an issue to turbopack since afaik everything that works with webpack should work in turbopack too

That's fair. I'm going to open an issue on vercel/next.js.

This aside though, it sucks to manually add the export for each ui element every time you install it but having autocomplete is worth it imo. Should we keep it explicit either way?

[juliusmarminge]

This aside though, it sucks to manually add the export for each ui element every time you install it but having autocomplete is worth it imo. Should we keep it explicit either way?

I honestly thought we already were using explicit due to the limitation in auto-imports.

[ahkhanjani]

I honestly thought we already were using explicit due to the limitation in auto-imports.

I made the commit that changed that due to us emitting type defs and the exports getting out of control. I'm dropping dev and build scripts inside ui package now for this reason.

[juliusmarminge]

I made the commit that changed that due to us emitting type defs and the exports getting out of control. I'm dropping dev and build scripts inside ui package now for this reason.

Hmm not sure I like that reasoning 😅 There's scripting that can be done to automate it if that's the main concern

But either way declaration emitting is to reduce the work the language server has to do and I'm not sure these React components are very heavy to infer... It's more for Zod, tRPC, Drizzle etc that does a lot of type shenanigans that you can notice the gains of declaration files vs live inference

[ahkhanjani]

Either way I'm fine with explicit exports just thought if we should file an issue to turbopack since afaik everything that works with webpack should work in turbopack too

Turns out webpack is the problem:
evanw/esbuild#2974 (comment)
webpack/enhanced-resolve#400

I tried recreating the issue without using an array. This was what we were doing:

{
  "exports": {
    "./*": [
      "./src/*.ts",
      "./src/*.tsx"
    ]
  }
}

I just accidentally figured out that it works just fine without the array:

{
  "exports": {
    "./*": "./src/*.tsx"
  }
}

This is not a turbo issue. We could continue using the wildcard export for convenience and lose autocomplete (note that autocomplete works fine after importing an element manually the first time in a .ts file).

What should we do?

[ahkhanjani]

Hmm not sure I like that reasoning 😅 There's scripting that can be done to automate it if that's the main concern

But either way declaration emitting is to reduce the work the language server has to do and I'm not sure these React components are very heavy to infer... It's more for Zod, tRPC, Drizzle etc that does a lot of type shenanigans that you can notice the gains of declaration files vs live inference

I agree. This PR fixes that. That was my bad 😅

We're keeping explicit exports then

[ahkhanjani]

That was the issue. Had to export each file individually

@jpainam You can keep the wildcard export if it's more convenient for you. Just replace the array with the string as I explained and see if it works.

[juliusmarminge]

The index file is a .ts so we need the array though (unless you change to index.tsx even for non-react stuff 😭)

[ahkhanjani]

The index file is a .ts so we need the array though (unless you change to index.tsx even for non-react stuff 😭)

index.ts is exported separately. The reason we had the array was for specific files like use-toast.ts which gets added when installing toast (or so it did. haven't tried recently)

[ahkhanjani]

I should've written the complete version of the exports field. My bad.

{
  "exports": {
    ".": "./src/index.ts",
    "./*": "./src/*.tsx"
  }
}

This should work IF you want to use the wildcard export. The recommendation is exporting each element separately. Also haven't figured out how to export wildcard .ts files yet. Probably add those manually

[juliusmarminge]

Cool cool 👍👍

To make explicit exports less of a headache and risk of forgetting to add them, we could add a small script wrapping shadcn cli that after installation,

• adds export paths in package.json
• runs formatting

[ahkhanjani]

Currently expo dev server is failing due to react versions clashing. Going to fix that

[dBianchii]

Shadcn will also update some of its components in general preparation for React 19:
https://ui.shadcn.com/docs/react-19

Not sure if they have updated it, just dropping the link here 👍

[ahkhanjani]

Shadcn will also update some of its components in general preparation for React 19: https://ui.shadcn.com/docs/react-19

Not sure if they have updated it, just dropping the link here 👍

I couldn't find anything we can change in the page you mentioned. Seems like something for third-party cli packages. Am I missing something?

[juliusmarminge]

Can remove all the forwardRef stuff but let's do that in a follow up PR

[ahkhanjani]

Shadcn will also update some of its components in general preparation for React 19: https://ui.shadcn.com/docs/react-19

Not sure if they have updated it, just dropping the link here 👍

Can remove all the forwardRef stuff but let's do that in a follow up PR

#1243

[bryanjtc]

Maybe you can reduce the pr size by reducing dependency version changes and moving bug fixes to other pull requests. The turbo issue seems to be fixed in 2.3.0

[ahkhanjani]

Maybe you can reduce the pr size by reducing dependency version changes and moving bug fixes to other pull requests.

We're actually only blocked by a pnpm bug atm

[ahkhanjani]

Maybe you can reduce the pr size by reducing dependency version changes and moving bug fixes to other pull requests.

Sorry it appears that I misread your comment. Most of the dependency updates are necessary imo because they add React 19 or Next 15 support. For example next-auth awaits for cookies etc.

[juliusmarminge]

I'll try and find some time to check if latest next auth works with our expo setup, if so we can bump that on next 14 - but I ran into some weird issues when updating last time :/

DONE

[ahkhanjani]

@juliusmarminge I think injecting auth as with react 18 will solve the type issue. Using react 18 types globally would be a little...

[juliusmarminge]

@juliusmarminge I think injecting auth as with react 18 will solve the type issue. Using react 18 types globally would be a little...

i don't think we'll be able to merge this PR until we've added expo 52 cause using different versions of react in a monorepo with hoisting is hard to get working from my experience...

let's just hope Expo's claim is holding up and that they actually do support monorepos now

[ahkhanjani]

i don't think we'll be able to merge this PR until we've added expo 52 cause using different versions of react in a monorepo with hoisting is hard to get working from my experience...

What if we just go with react 18 for now?

[juliusmarminge]

i don't think we'll be able to merge this PR until we've added expo 52 cause using different versions of react in a monorepo with hoisting is hard to get working from my experience...

What if we just go with react 18 for now?

even if you have r18 in package.sjon next app dir will use r19 - so you're just "masking" the issue. but.... sure??

[czystyl]

A potential solution to have React 19 inside the Expo too:
https://x.com/Baconbrix/status/1864785257297305833?t=nyfQ4F7CztTCXhUdYEilBQ&s=19