neondatabase / serverless

Connect to Neon PostgreSQL from serverless/worker/edge functions

Home Page:https://www.npmjs.com/package/@neondatabase/serverless

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Named export `Client` broken in `^0.7.0`

iolyd opened this issue · comments

Steps to reproduce

Minor version 0.7 (tested with 0.7.0 and 0.7.1) introduce breaking import error.

  1. Scaffold an ESM-first app with a neon client (Vite, or more specifically SvelteKit in my case)
  2. pnpm install @neondatabase/serverless@0.6.1
  3. Observe things working as expected
  4. pnpm up --latest (or pnpm install @neondatabase/serverless@latest)
  5. Observe below error (persisting even when using default export syntax)

Expected result

Named exports should be made available like in previous version (unless this is an expected breaking change), else document new import path(s).

Actual result

Get errors unless revert to previous minor version (0.6)

Environment

node v21.1.0

Logs, links

[vite] Error when evaluating SSR module /src/lib/db/db.server.ts: failed to import "@neondatabase/serverless"
|- [...]/node_modules/.pnpm/@neondatabase+serverless@0.7.1/node_modules/@neondatabase/serverless/index.mjs:2
  Client,
  ^^^^^^
SyntaxError: Named export 'Client' not found. The requested module './index.js' is a CommonJS module, which may not support all module.exports as named exports.
CommonJS modules can always be imported via the default export, for example using:

import pkg from './index.js';

    at ModuleJob._instantiate (node:internal/modules/esm/module_job:132:21)
    at async ModuleJob.run (node:internal/modules/esm/module_job:214:5)
    at async ModuleLoader.import (node:internal/modules/esm/loader:329:24)
    at async nodeImport ([...]/node_modules/.pnpm/vite@5.0.11/node_modules/vite/dist/node/chunks/dep-V3BH7oO1.js:50899:17)
    at async ssrImport ([...]/node_modules/.pnpm/vite@5.0.11/node_modules/vite/dist/node/chunks/dep-V3BH7oO1.js:50799:24)
    at async eval ([...]/src/lib/db/db.server.ts:4:31)
    at async instantiateModule ([...]/node_modules/vite/dist/node/chunks/dep-V3BH7oO1.js:50861:9)

Thanks for the report. The exact export mechanism has changed, in order to fix a bug in another context, but this should certainly still work.

I'll take a look first thing tomorrow.

I got same error

package.json

"@neondatabase/serverless": "^0.7.1",

command

esrun --tsconfig=db/tsconfig.json db/migrate.ts

tsconfig

{
  "compilerOptions": {
    "target": "ESNext",
    "module": "esnext",
    "resolveJsonModule": true,
    "isolatedModules": true,
    "allowJs": true,
    "skipLibCheck": true,
    "strict": true,
    "noEmit": true,
    "esModuleInterop": true
  }
}

I`m using @neondatabase/serverless package on Deno Deploy by npm import:

import { neon, neonConfig } from "npm:@neondatabase/serverless";

neonConfig.fetchConnectionCache = true;

const client = neon(env.DATABASE_URL);

It worked well before 0.7.1 (not sure about 0.7.0).
Now I got this error while trying to deploy to Deno Deploy by using deployctl (v.1.9.1) cli utility:

error: The deployment failed: BOOT_FAILURE

Uncaught SyntaxError: The requested module './index.js' does not provide an export named 'Client'
    at file:///node_modules/.deno/@neondatabase+serverless@0.7.1/node_modules/@neondatabase/serverless/index.mjs:2:3

Very sorry all, it looks like fixing #54 broke some other use cases. You should find that 0.7.2 addresses this. Please let me know (you just need to npm install @neondatabase/serverless@latest, of course).

In this release I've given up trying to wrap the CJS code as ESM, and we now export wholly separate CJS and ESM codebases. It seems like different bundlers and platforms do different things with CJS->ESM import, and we can't rely on making everyone happy. The one caveat to this new approach is that if you use require in some places and import in others, you'll now get separate copies of the code that don't share any config changes you make. So don't do that.

More generally, I'm working on a test suite that includes some common deployment scenarios. Hopefully this will guard against any similar future breakages.

0.7.2 has fixed the problem on Deno Deploy. Thanks.

Confirming 0.7.2 fixes the issue on my side.