Redwood v8.0.0 Upgrade Guide

Thanks for the offer @Tobbe. I decided to take the shortest path to resolve the issue for now, so I forked the docx package and made a couple of changes, including telling the package not to build as an ESM module. Now I can load the package statically, along with the types as well, and all is well. Of course, this references the package from a forked github repo rather than npm, which is not ideal, and thus, this is a temporary solution.

As a side note, I never did figure out why the base docx package behaves as a CommonJS package in Redwood v7.x. (I suspect the tsx version update in RW V8… but I haven’t confirmed.) Now, in V8, the base docx package behaved like an ESM module (which it should), along with all the issues that ESM currently brings into NodeJS applications. My future hope is the wider NodeJS and typescript community can help clean up some of the mud in the NodeJS/ESM world!

Thanks again… I’ll let you know if I need anything else! I didn’t want to waste your valuable time!

1 Like

Me too! And it looks like things are moving in the right direction https://webdeveloper.beehiiv.com/p/native-support-cjsesm-interoperability-begins-nodejs-22

1 Like

I am seeing the same behavior, were you able to fix? Here’s my full investigation:

Hey, I’m having some issues with production deployment to vercel after upgrading from v7.7.4 to v8.2.0. The issue only shows up when deployed to vercel, local development behaves as expected. The issue is with auth/cookies not being set after the POST request to /api/auth (which does get a 200 response), but does not have the setCookie header. The subsequent GET request to /api/auth?method=getToken also has a 200 response but does not return the logged in user. This results in the user not being able to get passed the login/signup page. The behavior does not show up when developing locally. I have a test repository with the minimal changes needed to reproduce GitHub - jgal1/redwood-vercel .

v7.7.4:
- Local developemnt works
- Production deploy DOES NOT have auth issues
- Code lives in the v7.7.4 branch of the linked repo
- Vercel Deployment: See next comment new users can’t post more than two links on this discussion…

v8.0.0:
- Local developemnt works
- Production deploy DOES have auth issues descibed above
- Code lives in the v8.0.0 branch of the linked repo
- Vercel Deployment: See next comment new users can’t post more than two links on this discussion…

v8.2.0:
- Local developemnt works
- Production deploy DOES have auth issues descibed above
- Code lives in the main branch of the linked repo
- Vercel Deployment: See next comment new users can’t post more than two links on this discussion…

Please let me know if you need any more information about my setup. The app is setup with a free supabase postgres instance (example format for env vars below), hosted on vercel with env vars set in the following format:
- SESSION_SECRET= secret obtained from running ā€˜yarn rw g secret’
- DATABASE_URL=See next comment new users can’t post more than two links on this discussion…
- DIRECT_DATABASE_URL=See next comment new users can’t post more than two links on this discussion…

The codebase for the reproduction lives at GitHub - jgal1/redwood-vercel . The v7.7.4 branch has the code which works for both local and vercel deployment, the v8.0.0 branch has the v8.0.0 code which does not work when deployed to vercel, and the main branch has the v8.2.0 version which also does not work when deployed to production.

To get a fresh repository for the minimal reproduction follow the below steps:

yarn create redwood-app redwood-vercel --typescript
cd redwood-vercel && yarn install
yarn rw setup ui tailwindcss
yarn rw setup auth dbAuth
yarn rw setup deploy vercel

The vercel deployment uses the standard redwood preset, and the only requirement on vercel is to set the environmental variables which are stated above.

This shouldn’t make any difference for this issue but for my specific case, to connect to the supabase postgres instance the schema.prisma file needs the following edit to the ā€˜datasource’ config:

datasource db {
  provider  = "postgresql"
  url       = env("DATABASE_URL")
  directUrl = env("DIRECT_DATABASE_URL")
}

For local development, the DATABASE_URL and DIRECT_DATABASE_URL should be the same and point to a local postgres instance

Please let me know if there is anything I can do to help debug, for example any vercel permissions issues viewing the deployed domains, or vercel logs.

As a new redwood community discussion my last post couldn’t have more than 2 links, here is the rest of the info:

Please let me know if you need any more information about my setup. The app is setup with a free supabase postgres instance (example format for env vars below), hosted on vercel with env vars set in the following format:
- SESSION_SECRET= secret obtained from running ā€˜yarn rw g secret’
- DATABASE_URL=postgres://postgres.example:examplepw@aws-0-us-west-1.pooler.supabase.com:6543/postgres?sslmode=require&pgbouncer=true&connection_limit=1
- DIRECT_DATABASE_URL=postgres://postgres.example:examplepw@aws-0-us-west-1.pooler.supabase.com:5432/postgres?sslmode=require
- NODE_ENV=production

1 Like

The working deployment v7.7.4 can be tested live at https://redwood-vercel-git-v774-jgal1s-projects.vercel.app/

The broken auth deployment for v8.0.0 can be seen at https://redwood-vercel-git-v800-jgal1s-projects.vercel.app/

Do you find any solution for this ? I have the same problem and I try until 8.4.0

I check your description and this is exactly the same issue

Wanted to say thanks for the all the effort that’s gone into this team :pray:

Upgraded to latest pretty smoothly, had a deep import issue but thanks to the in-depth guide, fixing was straightforward.

3 Likes

The migrated tsconfig.json on the API side also made me stumble for a moment (to be frank, the nitty-gritty of it is all a little over the top of my head … cherish these rare moments in between these rather academical issues when we actually get to write code and implement new stuff :upside_down_face:).

So i ran into

The current file is a CommonJS module whose imports will produce ā€˜require’ calls; however, the referenced file is an ECMAScript module and cannot be imported with ā€˜require’. Consider writing a dynamic ā€˜import(ā€œlivekit-server-sdkā€)’ call instead.
To convert this file to an ECMAScript module, change its file extension to ā€˜.mts’, or add the field "type": "module" to ā€˜/home/phil/prog/interview-tool/interviewtool/api/package.json’.ts(1479)

But as it turns out, this is only an indicator that the package.json of the library i was importing had an issue: Using ESM-style imports from `livekit-server-sdk` gives warnings ("current file is a CommonJS module") Ā· Issue #357 Ā· livekit/node-sdks Ā· GitHub

So i understand this setting is simpler ā€œstricterā€ and thus can help identify compatibility issues in other libraries as well.

BTW big kudos to @Tobbe for pointing me at publint via fix(ogimage): Corrected package.json exports by Tobbe Ā· Pull Request #11724 Ā· redwoodjs/redwood Ā· GitHub – awesome tool that helps identify & solve these issues easily, while providing lots of additional information for those wanting to go deeper into the rabbit hole.

@klobetime were you ever able to solve your problem?

Hi :wave:

I started playing around in a version 7, and am currently migrating some components over to a new install on version 8.

I am struggling with understanding how to resolve the changes described in ā€œRedwood package imports and exportsā€ and wondered whether you may have any insights.

Specifically, I had an old component that imported

import { InputFieldProps } from '@redwoodjs/forms/dist/InputComponents'

I understand this no longer works. I used this interface downstream to create a typed component myself. I checked out the relevant package.json](redwood/packages/forms/package.json at main Ā· redwoodjs/redwood Ā· GitHub) but I do not really understand how I might get this type information anymore.

Might any of you have insights on how to deal with the changes to the deep importing in Redwood@8?

Thanks for the great upgrade!

@chartgerink Thanks for letting me know. That was an oversight on our part.
PR to fix it: fix(forms): Re-export InputFieldProps by Tobbe Ā· Pull Request #11879 Ā· redwoodjs/redwood Ā· GitHub

1 Like