[Turbopack] LICENSE file parsing error when using drizzle-orm/libsql

[madebycm]

Verify canary release

• I verified that the issue exists in the latest Next.js canary release

Provide environment information

Operating System:
  Platform: darwin
  Arch: arm64
  Version: Darwin 24.5.0
  Available memory (MB): 16384
  Available CPU cores: 10

Binaries:
  Node: 22.7.0
  npm: 10.8.2
  bun: 1.2.19

Relevant Packages:
  next: 15.5.0
  react: 19.0.0
  react-dom: 19.0.0
  typescript: 5.7.2

Next.js Config:
  output: N/A

Which area(s) of Next.js are affected? (leave empty if unsure)

Turbopack

Which stage(s) are affected? (leave empty if unsure)

next build (local)

Describe the Bug

Turbopack fails to build when using drizzle-orm/libsql. It incorrectly attempts to parse the LICENSE file from node_modules/@libsql/hrana-client/LICENSE as JavaScript code.

Error output:

Error: Turbopack build failed with 1 errors:
./node_modules/@libsql/hrana-client/LICENSE:1:5
Parsing ecmascript source code failed
> 1 | MIT License
    |     ^^^^^^^
  2 |
  3 | Copyright 2023 the sqld authors
  4 |

Expected ';', '}' or <eof>

Expected Behavior

Turbopack should not attempt to parse LICENSE files as JavaScript. The build should complete successfully.

Link to the code that reproduces this issue

https://github.com/madebycm/turbopack-license-bug

To Reproduce

1. Clone the repository

git clone https://github.com/madebycm/turbopack-license-bug
cd turbopack-license-bug

2. Install dependencies

npm install

3. Run build with Turbopack

npx next build --turbopack

The build will fail with the LICENSE parsing error.

Additional Context

Important: This bug only occurs when importing from drizzle-orm/libsql:

• ✅ Works: import { createClient } from '@libsql/client'
• ❌ Fails: import { drizzle } from 'drizzle-orm/libsql'

The issue appears to be related to how Turbopack handles transitive dependencies when certain import patterns are used.

Workaround: Use standard Webpack build without --turbopack flag:

npx next build

This blocks Turbopack adoption for any application using Drizzle ORM with SQLite/LibSQL.

_PACK-5319

[titouv]

Linking this Twitter feed with useful comments from Tim Neutkens

[robcaldecott]

We have the same issue importing New Relic in our instrumentation.ts file. Happy to open a new ticket but it looks to identical to this one.

[bgw]

I'm still root-causing this, but a workaround appears to use pnpm or bun with bun install --linker isolated: https://bun.com/docs/install/isolated

[madebycm]

I'm still root-causing this, but a workaround appears to use pnpm or bun with bun install --linker isolated: https://bun.com/docs/install/isolated

Thanks for the heads up! Great news - can confirm pnpm immediately fixes it. Not sure if this is related to bun itself.

--turbopack so far is showing significant build improvement times 👍

[bgw]

This seems to be an issue with the dynamic require in the libsql npm package here:
https://github.com/tursodatabase/libsql-js/blob/v0.5.17/index.js#L26

We cannot infer all the possible values of currentTarget(), so we're forced to read modules for module '@libsql' with subpath '/' <dynamic>:

The v0.6.0 version of libsql appears to have this bug fixed, so you can use an npm override to force that version.

+  "overrides": {
+    "libsql": "v0.6.0-pre.18",
+  },

I don't think it's practical for us to try to fix this issue in Turbopack, though it is a bit weird that webpack doesn't have an issue here, as I would expect it to.

One issue we can potentially fix in Turbopack is that we don't output an import trace in this case. That would make this way easier to debug. I've spent some time walking through the code, but I'm still not sure why we don't.

[bgw]

I've created tursodatabase/libsql-js#200 upstream for libsql v0.5 (the current stable release). v0.6 does not have this problem.

EDIT: This was merged upstream, but reverted due to an issue in esbuild. tursodatabase/libsql-js#204 should hopefully fix this.

@mischnic pointed out that this failure seems to come from the NFT ("node file trace") step in Turbopack, which would explain both the lack of import traces and why we're divergent from webpack here. Apparently we have some logic for other similar cases: #71713

[madebycm]

Good insights @bgw, your analysis makes sense.

For anyone still encountering this issue - if you can't override and use the v0.6.0 pre-release of libsql - here's my "fix" 😅

"scripts": {
   "build": "rm -f ./node_modules/@libsql/hrana-client/LICENSE && next build --turbopack"
}

(it's resurfaced in our builds even with both pnpm and npm ... nuke it and move on while still enjoying the significant turbopack gains)

[nnennajohn]

@madebycm , thank you for that. Quick and dirty, but works.