Cannot read properties of undefined (reading 'Client') error in Next.js when .mjs files are configured to be handled by Webpack

[joulev]

Steps to reproduce

1. Clone https://github.com/joulev/debug/tree/drizzle-orm-fail-webpack-config

2. Add an .env file at the same level with package.json with DATABASE_URL being the connection string of any Neon databases. Empty databases work too, no migrations or schema pushes necessary.

3. pnpm install, then pnpm build

4. You will see the error

   TypeError: Cannot read properties of undefined (reading 'Client')
   

5. If you remove the following lines from next.config.js

   config.module.rules.push({
     test: /\.m?js$/,
     type: "javascript/auto",
     resolve: {
       fullySpecified: false,
     },
   });

   and rebuild again, it will function normally and get an error like relation "a_table_that_does_not_exist" does not exist (expected error).

Expected result

Even with the Webpack config lines added, it should still work (which means it will throw that the table doesn't exist, and if the table actually exists it will query and return the data normally).

Actual result

It gets the TypeError above.

Environment

@neondatabase/serverless v0.6.0

macOS 14.1.2 (Sonoma), node v20.3.1, pnpm v8.11.0

Logs, links

Correct error message

NeonDbError: db error: ERROR: relation "a_table_that_does_not_exist" does not exist

Caused by:
    ERROR: relation "a_table_that_does_not_exist" does not exist
    at execute (/Users/joulev/dev/www/debug/.next/server/chunks/566.js:9:441)
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
    at async Page (/Users/joulev/dev/www/debug/.next/server/app/page.js:1:1693) {
  code: '42P01',
  sourceError: undefined
}

Buggy error message

TypeError: Cannot read properties of undefined (reading 'Client')
    at 4804 (/Users/joulev/dev/www/debug/.next/server/chunks/804.js:25:64)
    at __webpack_require__ (/Users/joulev/dev/www/debug/.next/server/webpack-runtime.js:1:145)
    at 2475 (/Users/joulev/dev/www/debug/.next/server/app/page.js:1:1616)
    at Function.__webpack_require__ (/Users/joulev/dev/www/debug/.next/server/webpack-runtime.js:1:145)
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
    at async collectGenerateParams (/Users/joulev/dev/www/debug/node_modules/.pnpm/next@14.0.1_react-dom@18.2.0_react@18.2.0/node_modules/next/dist/build/utils.js:883:17)

Additional contexts

• It's very likely the issue reported by @/feliche93 here using the serverless/websocket driver fails locally? #26 (comment).

• Until Next.js v14.0.4-canary.33, this Webpack config was necessary for Next.js to handle ESM files well, ref: ESM in .mjs files cause a dev mode runtime error vercel/next.js#17806 (comment). Now, although Next.js has patched this, the patch is still very new (a few days old) and in the ecosystem many packages/plugins have baked this workaround config to their source code and haven't updated them. Hence for a while more, this config is likely to be added (directly by the developer, or indirectly by third-party plugins) to many codebases.

  Still, even when Next.js has patched this, I think it's still a bug on @neondatabase/serverless's side because things, well, shouldn't break simply because the user opts to handle .mjs files as well.

[jawj]

Thanks for this report, I'll take a look soon.

[jawj]

OK, I can reproduce both the problem (Cannot read properties of undefined (reading 'Client')) and the solution (deleting the custom webpack config).

I'm not a Next.js/Webpack/module resolution expert, but I can't immediately identify anything wrong in the way we export CJS and ESM. Since things now work fine out-of-the-box, and fail when using the custom-config workaround, I'm not sure that the bug is on our side.

I agree, of course, that it would be nice if it would just work, wherever the bug is ...

[jawj]

@amitdahan Thanks very much for establishing that the problem here was down to the scourge of default imports!

@joulev I think version 0.7.0, just released and based on 45e34e1, should fix this issue. Please do let us know either way.

[joulev]

I can confirm v0.7.0 works perfectly! Thanks so much to both of you!