fix(preservemodules): temporarily remove preserveModules

[maiieul]

What is it?

• Feature / enhancement
• Bug
• Docs / tests
• Other

Why is it needed?

For two reasons:

• the namespace issues (see temporary-fix(big bundle & cannot-resolve-symbol): revert to non-optimized bundling until it's fixed in qwik #521 which also links to Bug: Cannot resolve symbol s_c7PiYJ1s0GU... Error code (31) - Namespace conflicts #519 for a more thorough explanation)
• the SSG build hang issue (see Bug: AccordionTrigger and AccordionContent yields error during static build #577 wich is likely the same bug as Bug: Cannot resolve symbol s_c7PiYJ1s0GU... Error code (31) - Namespace conflicts #519)

Until QwikDev/qwik#5473 gets solved in Qwik, I say we temporarily disable preserveModules. We will have less performance (it should be about 11kb more instead of 40 now that the repo is cleaned up) in favor of more stability.

Checklist:

• My code follows the developer guidelines of this project
• I have performed a self-review of my own code
• I have ran pnpm changeset and documented my changes
• I have add necessary docs (if needed)
• Added new tests to cover the fix / functionality

[changeset-bot]

⚠️ No Changeset found

Latest commit: e138c29

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[shairez]

Thanks @maiieul
I personally prefer to fix the issue in Qwik first

My question now is - is this critical for the release of headless and fluffy, or is it just an optimization that could be done later?

[maiieul]

I think it's a bit critical yes. Fluffy should provide the Accordion components named as "Accordion", and right now we can't. Also if we want to appear as a serious alternative to other frameworks even for UI, we need to have a docs site that feels more performant (which is not the case right now because of the CLS issues and the big bundle with shikiji. Besides, the namespace issue will be problematic for any other component where we'd like to reuse the same names for the styled components as the headless components.

For me it's having "preserveModules" that is an optimization that can be added later. It's also very easy to add back. For me the problem is that we don't know when this will be fixed in Qwik. Could be in 3 months but maybe 6 or even a year from now...

[maiieul]

P.S. I think we need to prioritize our DX (fast development & no bugs) before slightly better perf for the end user for now.

Also I believe that the fact that we can't really use preserveModules with the current conditions should be pressing Misko or Manu to prioritize this before other issues. Helping library authors is vital to Qwik's ecosystem and I'm sure they understand that.

[PatrickJS]

LGTM

[maiieul]

If we are not merging this, then it also means we'll have to ask all our users at some point to change the name of their components - unless we can find a name that can stay, but I will always prefer "Accordion" to anything else.

So if we don't merge this, what prefix/suffix should we use?
We cannot use "Accordion"

So a few ideas:

Accordion$
QUIAccordion
$Accordion
AccordionQ

In my opinion Accordion$ or $Accordion look the cleanest. Maybe $Accordion would be less confusing in the sense that Accordion$ could let people think that it's useful for the optimizer? But also Accordion$ feels more natural. All in all I prefer "Accordion" ofc.

Usually things like "_Accordion" are for internal use, no? It feels awkward to me. $ is more in the spirit of Qwik if we decide to go down that path 😉

[shairez]

merged
I've commented the lines instead of deleting them, and added #606 as reminder