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.

[juliusmarminge]

This upgrade messed up the expo auth last time I tried it. Didn't investigate further what it was though

[ahkhanjani]

I'll take a look

[juliusmarminge]

??

[ahkhanjani]

Turbo 2.2 crashes my projects in my work repo. I think it also did in this one. Not sure. I'll try again

[ahkhanjani]

Yup. Also panics here. In every app dev server (nextjs/expo)

[dBianchii]

Yeah, it happens with me as well. 2.2.3 is a bit better, but it still happens

[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

[ahkhanjani]

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

Totally agree

[ahkhanjani]

Encountered a potential pnpm bug while trying to fix expo
pnpm/pnpm#8715

[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