[🐞] 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 https://github.com/BuilderIO/qwik/issues/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 6) Put a breakpoint on line 2087 (here, the transform function is setting the newOutput modules into the currentOutputs Map) 7) Start the build.client debugger 8) In your WATCH panel, observe that at currentOutputs[31], there is a key with entry_AccordionRoot.js 9) 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. 10) 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 🙏

[wmertens]

@diecodev what is the crash message? Qwik itself has a lot of exports...

[diecodev]

@wmertens it does not show a error by itself, in console you have a reference to a github docs line 31 that says something about the qrls. you can check the error qwik refer in here

and this is the error in terminal:

Maybe this can be useful: I got 2 module exports, the default one (qwik-sonner) and the headless version (this one is for the future usage in qwik-ui, is a submodule, so you can access to it importing the components from qwik-sonner/headless), so my vite config has 2 entry points, one for the styled version and another for the headless one. The problem occurs when the styled was importing the headless (what makes sense, because the styled version only apply styles to the headless). So, I solved the problem building the styled and headless version separately. IDK why but I think something in the vite config is not resolving the paths or something else, idk honestly.

---

@rafalfigura btw, there is a new version (the v1.0 release) of qwik-sonner where I solved this problem for the component.

[thejackshelton]

Hey guys, so the issue involves the function declaration names. In Qwik UI v0.4 we have gotten around this by providing an alias alongside preservemodules.

For example exporting a function called HAccordionRoot, and then having an alias like AccordionRoot.

A hacky workaround for now, but better than nothing.