No way to get this working, Debian 12

[PenttiFlasheye]

I had Rollup installed in the old installation of Debian 11 and it worked without any problems. Installed JsDoc which exploded the whole npm so Rollup started to throw errors. So, I took backups and reinstalled the whole system with the current Debian 12. Now, I can't find any way to make Rollup to work again. It just throws node-resolve errors for the project (any commits which worked earlier). I think the error is the same as it was when installing JsDoc broke it:

(!) Plugin node-resolve: Could not resolve import "three/build/three.module.js" in /home/pparnane/Flasheye/felib-local/src/shims/three/core.js using exports defined in /home/pparnane/Flasheye/felib-local/node_modules/three/package.json.
(!) Unresolved dependencies
https://rollupjs.org/troubleshooting/#warning-treating-module-as-external-dependency
three/build/three.module.js (imported by "src/shims/three/core.js")

[potatohoney-p]

The useful part of that warning is using exports defined in .../three/package.json. The installed Three.js package does not expose three/build/three.module.js as an importable subpath, even though the file exists.

In src/shims/three/core.js, keep the same imports/re-exports but change the module specifier to three. For example, if the shim re-exports the library:

export * from "three";

Or for a named import:

import { Vector3 } from "three";

I checked a minimal build with three@0.158.0, rollup@4.53.3, and @rollup/plugin-node-resolve@16.0.3. The deep import produced the same export-map warning and remained external. Changing only the specifier to three produced no warnings and no external imports; the generated module ran successfully. In that Three.js version, the root export has "import": "./build/three.module.js", so the public import still selects the ESM build.

This verifies the specific warning, not the entire Debian project. The original installed versions and lockfile are not included here, so I cannot tell what changed during the reinstall. Comparing those with the previous working lockfile would be the next check if other errors remain. Marking the deep path as external would only leave that unresolved import in the output, rather than fix it.