Imports aliases from node_modules (_tsup-dts-rollup)

[yoannfleurydev]

Context

What's your version of nuqs?

"nuqs": "2.0.4"

What framework are you using?

• ✅Next.js (app router)

Which version of your framework are you using?

Operating System:
  Platform: darwin
  Arch: arm64
  Version: Darwin Kernel Version 23.6.0: Mon Jul 29 21:14:04 PDT 2024; root:xnu-10063.141.2~1/RELEASE_ARM64_T8122
  Available memory (MB): 24576
  Available CPU cores: 8
Binaries:
  Node: 20.16.0
  npm: 10.8.1
  Yarn: 1.22.19
  pnpm: 9.12.2
Relevant Packages:
  next: 14.2.14 // An outdated version detected (latest is 15.0.1), upgrade is highly recommended!
  eslint-config-next: 14.2.14
  react: 18.3.1
  react-dom: 18.3.1
  typescript: 5.6.2
Next.js Config:
  output: N/A

Description

I have a project for a client in which I use 🚀 Start UI [web] which uses nuqs. At the moment, nuqs wants to import some aliases from node_modules. It is the only package that want to do that.

If I have some time in the next few days, I'll check what is happening with the bundling part, maybe some export that aren't correct in the package.json or something else like that.

Reproduction

[franky47]

Ah, I had seen someone reporting something similar, but for adapters, could you try that for me please? What IDE are you using (looks like Jetbrains UI) ?

This is likely related to the way we bundle the .d.ts, using the experimental option in tsup to split the server & client bundles.

[yoannfleurydev]

Can confirm I have the same behavior with NuqsAdapter. I'm using VS Code 😊

[yoannfleurydev]

TypeScript: 5.6.2

[franky47]

Looks like I can (partially) reproduce with a tsconfig.json set to "moduleResolution": "bundler":

[yoannfleurydev]

Can reproduce in a fresh 🚀 Start UI [web] (which use moduleResolution: "bundler") except this time it does not even propose the "correct" import. I can add the import manually and it works by the way.

[franky47]

Preview package to try a potential fix:

pnpm add https://pkg.pr.new/nuqs@719

[yoannfleurydev]

No import at all at the moment (I restarted TS server).

[franky47]

Some notes:

Creating a brand new Next.js app (with pnpm create next-app) works fine with nuqs 2.1.1, and with the following generated tsconfig.json:

{
  "compilerOptions": {
    "target": "ES2017",
    "lib": ["dom", "dom.iterable", "esnext"],
    "allowJs": true,
    "skipLibCheck": true,
    "strict": true,
    "noEmit": true,
    "esModuleInterop": true,
    "module": "esnext",
    "moduleResolution": "bundler",
    "resolveJsonModule": true,
    "isolatedModules": true,
    "jsx": "preserve",
    "incremental": true,
    "plugins": [
      {
        "name": "next"
      }
    ],
    "paths": {
      "@/*": ["./src/*"]
    }
  },
  "include": ["next-env.d.ts", "**/*.ts", "**/*.tsx", ".next/types/**/*.ts"],
  "exclude": ["node_modules"]
}

It does include moduleResolution: bundler though, so maybe the problem is somewhere else.

[franky47]

Ok so after trying a lot of different things that didn't give any different results, I started bisecting away dependencies from the start-ui-web repo (rip & tear style), to see if there was a specific dependency that could throw Intellisense out of whack.

I don't yet have hard evidence, but it looks like it's the amount of dependencies that causes the issue, not a specific one in particular. Pruning them to only keep what you'd find in a stock pnpm create next-app does work. Still works with about 1/4 the total dependencies count, but doesn't work with about half.

Unfortunately there seems to be a cache in place, which means that when it starts working, we can't go back to a state where it didn't work by just re-adding the dependencies we just removed.

Sounds like a VSCode bug rather than something we can do on our end.