-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[🐞] Duplicate implementations of JSXNode Errors in RC, v0.103 #3883
Comments
I've come across this issue in |
FYI @n8sabes , I've managed to "fix" this by merging all my original entry points into a single one. But after this the qwik compiler is too heavy for my machine and the build fails because it runs out of heap (~about 24k qwik components) |
@NiklasPor do you really need component$s? Or could lite components suffice? Then maybe you can skip the build step and just export functions that call jsx? |
Hm, about one third of the components use a context hook and if I remember correctly they don't work in lite / inline components. I'll consider throwing away the feature which uses the context, so that I atleast can publish a stable version 👍 Still I think it would be great if we could maybe reach a point in the future, where it's possible to add multiple entrypoints, just like with a regular vite config / js package. A lot of large packages in the JS ecosystem use the functionality. Probably a possibility for later point on some roadmap 👀 |
You could also only build one lite and one regular component and use those as templates for the rest |
Lite components seem to work fine. Just in dev mode ( |
Alright, so the icon package now works with multiple entrypoints + only lite components – but the warning is now back that I'm using multiple entrypoints. Thanks for the suggestions @wmertens |
I might be hitting this: QwikDev/qwik#3883
The warning is still there when using |
Hi! I have seen the workaround commited from @kisaragi-hiu referencing this issue but it removes completely all errors thrown to the shell. As a temporal workaround to avoid the noise caused using // entry.ssr.tsx
import { isDev } from '@builder.io/qwik/build'
if (isDev) {
const consoleWarn = console.warn
const SUPPRESSED_WARNINGS = ['Duplicate implementations of "JSXNode" found']
console.warn = function filterWarnings (msg, ...args) {
if (!SUPPRESSED_WARNINGS.some(entry => msg.includes(entry) || args.some(arg => arg.includes(entry))))
consoleWarn(msg, ...args)
}
} |
Works fine, thank you. :) However, I guess solving the problem actually would be a better solution at the end of the day. :) |
I'd like to add that it seems like the error is harmless in the case of the icons package, but it can lead to actual things not working, see #4436 |
I very strongly second this, the only reasons the icons package is working, is that I'm not using any If I'd need to guess, the reason seems to be connected to the multiple entrypoints. Probably qwik is only perprocessing specfic entrypoints? |
Has there been any progress on this issue? I currently cannot use the icons package because It is breaking parts of my app. |
So this error means that Vite has somehow packaged up the JSX code twice! And this is an early error so that you don't go nuts later with strange behavior.... So if you see this error, the question you should be asking is why are there two copies of JSX implementation in the system. This is not an issue with Qwik, but rather how you have the vite configured.... If someone can give me a simple reproduction that you think should be fixed, I will look into it. |
@mhevery I posted a repro in #4436, https://stackblitz.com/edit/qwik-starter-wadzsa?file=src/routes/index.tsx it happens in dev mode too, and it breaks in production. Qwik is definitely packaged only once. The error indicates that the JSXNodeImpl class is instantiated twice, but I can't figure out how. |
I'm pretty sure this happens, because you also use multiple named exports in the Maybe there's something hardcoded in Qwik which looks exactly for an entrypoint
The docs also impose some restrictions on how the file must be named:
In
I would love it if we get to support multi-entrypoint packages. |
@NiklasPor well you just solved why qwik-ui doesn't work 😅 cc @shairez I'll see if I can fix styled-vanilla-extract. I'm assuming the duplicated JSXNodeImpl is because of the optimizer bundling it directly and then vite bundling it separately where it wasn't done by the optimizer. If so, the optimizer could instead look at the imports and see if qwik is imported instead of only relying on the filename |
Always happy to help, I'd love it when we get the packages to work without problems – kinda important for the ecosystem 😁 |
I upgraded the repro to latest everything and built styled-vanilla-extract with .qwik.mjs extensions, but it didn't help. https://stackblitz.com/edit/qwik-starter-8kdqva?file=package-lock.json,package.json |
I figured it out. In the repro above I added What happens is: Vanilla-extract runs the css.ts files at build time and generates a file that imports This generated import doesn't get bundled by vite. You can see it at the top of server/entry.preview.mjs: import { styled } from "styled-vanilla-extract/qwik-styled"; I added the vite inspect plugin to the repro so you can see all the transforms. Everything seems correct, but the dev build does import core.prod.mjs even though I can't find what imports it. For dev mode, I assume the same thing is happening. So the problem is either:
I think it would be safer if the server build did not bundle qwik |
BTW @NiklasPor not that it seems to make a difference, but your package.json does not include the |
Ok I solved it. This is what happens:
So by having a key "qwik" at the root of your package.json, it will be bundled into the ssr build, which fixes the duplicate jsxnode. This is somewhat documented, so it's a matter of making it more clear. Ideally, the node_modules I do think it's a bit confusing to have the So @NiklasPor add the "qwik" attribute to your package. @mhevery @manucorporat what should the "qwik" attribute point at, exactly? And how to make it easier to discover that ".qwik.js" wasn't generated or that the "qwik" attribute is missing? |
Awesome @wmertens, I'll check If I can finally fix the package with this! 😅 |
@wmertens Seems like my local testing everything went fine with this, can't believe that this small thing made the change 🤯 I'll check if it works with the community, thanks a lot ❤️ |
Maybe I am misunderstanding the question, but I think the
|
+1 to better document this. Also maybe add a section to the documentation explaining a common failure mode and then update the error with a pointer to the documentation saying maybe this is what is going on? Any chance @wmertens or someone could create a PR for that? Please 🍒 on top? |
I did try that but it complains somewhere. It expects a string. Presumably it's used elsewhere, the vendorIds just use it as a truthy value. |
What is the error? |
OK, I think the code is here: https://github.com/BuilderIO/qwik/blob/main/packages/qwik/src/optimizer/src/plugins/vite.ts#L704 |
...which is indeed inside the code you point at. And the vendorRoots are used by the optimizer as input file: https://github.com/BuilderIO/qwik/blob/92b77bbe4dbbe623f26dcaf3165e3e1940b6b4af/packages/qwik/src/optimizer/src/optimizer.ts#L68 So it should be a single root file that encompasses all qwik code. Would be nicer as an array. |
😁 PR ? |
Which component is affected?
Qwik Runtime
Describe the bug
I'm getting
QWIK WARN Duplicate implementations of "JSXNode" found
warnings when using Qwik Styled Vanilla Extract.This happens with RC1 Starter, following Integration Docs. Please see Loom Example, if needed.
Also, with v1.0 around the corner, there are open PRs and Issues with styled-vanilla-extract that should get a little love since it's listed in the official documentation integrations section.
Cc: @manucorporat, @wmertens
Reproduction
https://www.loom.com/share/9eab1daa92f0431d848f35ea67899258
Steps to reproduce
System Info
Additional Information
No response
The text was updated successfully, but these errors were encountered: