[🐞] Library mode + preserveModules -> error in consumer project: Cannot resolve symbol s_c7PiYJ1s0GU — QWIK ERROR Error: Code(31)

[maiieul]

Which component is affected?

Qwik Optimizer (rust)

Describe the bug

Related to #5097, but creating another issue because the two will probably be solved independently.

In an attempt to solve the big bundle and tree-shaking issue in qwik-ui, which is also an issue for any other qwik library using the library starter, @shairez and @wmertens found that setting build.rollupOptions.output.preserveModules to true can work around the issue. But the problem is that this introduces a namespace issue in preview and production with "error code 31" and the error message "Cannot resolve symbol s_c7PiYJ1s0GU".

So using

    rollupOptions: {
      output: {
        preserveModules: true,
        preserveModulesRoot: 'packages/kit-headless/src',
      },
    },

if the library has a component$ named AccordionRoot, and then I define export const AccordionRoot = component$(...) in the local app, the AccordionRoot component from the library will be overridden by the AccordionRoot in the local app, leading to "Cannot resolve symbol s_c7PiYJ1s0GU... Error code (31)" types of errors when symbols cannot reach the qwik-ui's AccordionRoot code as it isn't there.

We believe the code isn't there because it is the local project's AccordionRoot that is in the build output instead.

Reproduction

https://github.com/maiieul/qwik-libraryMode-and-preserveModules-namespace-issue-repro

Steps to reproduce

To see the error message:

1. Clone the repo
2. npm i (npm will make the debugging step easier)
3. npm run preview

Go into src/components/accordion-root/index.tsx and change the const to AccordionRoot2 and the error will go away.

System Info

System:
    OS: Linux 6.5 Fedora Linux 38 (Workstation Edition)
    CPU: (16) x64 13th Gen Intel(R) Core(TM) i5-1340P
    Memory: 17.00 GB / 31.04 GB
    Container: Yes
    Shell: 3.6.1 - /usr/bin/fish
  Binaries:
    Node: 20.9.0 - /usr/local/bin/node
    npm: 10.1.0 - /usr/local/bin/npm
    pnpm: 8.10.5 - ~/.local/share/pnpm/pnpm
  Browsers:
    Chrome: 119.0.6045.159
  npmPackages:
    @builder.io/partytown: ^0.8.1 => 0.8.1 
    @builder.io/qwik: ^1.2.18 => 1.2.18 
    @builder.io/qwik-city: ^1.2.18 => 1.2.18 
    @builder.io/qwik-react: 0.5.0 => 0.5.0 
    undici: 5.27.0 => 5.27.0 
    vite: 4.5.0 => 4.5.0

Additional Information

@shairez and I have been through a lot of steps to identify the bug, but we believe it's an optimizer issue and couldn't get further. It will probably be easier to go through this in a live session, but I wrote the steps here in case someone has to go over them later on.

To understand the error:

1. Go into VScode debugger
2. Open node_modules/@builder.io/qwik/optimizer.cjs
3. Watch for newOutput, currentOuputs, and deps
4. Put a breakpoint on line 2087 (here, the transform function is setting the newOutput modules into the currentOutputs Map)
5. Start the build.client debugger
6. In your WATCH panel, observe that at currentOutputs[31], there is a key with entry_AccordionRoot.js
7. In your WATCH panel, observe that at newOutput.modules[10], the path is "/qwik-ui-tabs-repro/src/entry_AccordionRoot.js", but at currentOutputs[31], there is already a key with entry_AccordionRoot.js that has already been set at line 2020.
8. Press the "Continue (F5)" button 10 times and see the entry_AccordionRoot.js of the local project being overridden by the one from qwik-ui. I was expecting the opposite, so I guess that by the time this override happens, the local project entry file has already been outputted into the build folder and so Rollup, Vite, or the Plugin can't output it again.

Either way, we believe the crux of the issue lies in the fact that the path is the same for both AccordionRoot components ("entry_AccordionRoot.js"). A global search makes it look like this is being set in packages/qwik/src/optimizer/core/src/entry_strategy.rs.

[wmertens]

Makes sense, can be solved by changing the names of entries to include their path. I suppose that happens in the optimizer?

[maiieul]

Yes, that's what we were thinking. I suppose this happens in packages/qwik/src/optimizer/core/src/entry_strategy.rs.

I guess we could add a hash to the names of entries like it's done for symbols?

[rafalfigura]

I have the same issue. But it's happening after using <Toast /> from diecodev/qwik-sonner. Maybe @diecodev will be helpful here

[diecodev]

@rafalfigura, for some reason, the vite config (qwik city template) crash when you install a dependency with more than 1 module export (in qwik sonner, I am exporting the styled version and the headless version). I tried to compile the website of qwik sonner, and the CI couldn't build. After a lot of hours of trying to solve the problem, I noticed that the only change I made was the custom entry points in vite config (library mode). So maybe there is something in the qwik plugin (qwik city template) or in the config that qwik uses by itself. I will take a look at this today. Hopefully, I can create a PR that solves this error. If I'm not, I think I am going to be forced to only export one file.

@maiieul, which means the qwik sonner could not be used in qwik-ui because the headless version couldn't be exported

[maiieul]

@diecodev if you can't find a solution we could have a look sometime in June (this month is pretty busy for me). But it doesn't seem qwik-sonner is using preserveModule @rafalfigura. Unless you just removed it @diecodev? If there's no preserveModules in qwik-sonner, I doubt this is a related issue. @rafalfigura please create an issue in https://github.com/diecodev/qwik-sonner/issues and link to this issue if you still believe it's related 🙏