Parsing error for .jsx files in Node Modules in dev

[ryansolid]

Not sure if I'm just missing something, but it appears that the transform stage isn't performed in dev (or this parse error occurs before it gets to it) when using JSX files in node_modules. It appears to choke during optimizeDeps. Unclear if transform is intended to happen here in dev and/or there is a way to opt-in.

JSX files work fine in the src folder. If I use precompiled JS of the Node Modules or do the production build everything works as expected.

Screenshot of the error:

I can report an issue and provide a reproduction if needed. But was thinking this might be simpler than that.

The use case is for Solid which does custom transformations on JSX that differ depending on target (client, server, hydration) similar to Svelte, so it is common to ship .jsx files in shared modules.

Thanks for any assistance.

[patak-dev]

This may be an issue with pre-bundling that needs to be fixed, but as a workaround, did you try excluding these dependencies? https://vitejs.dev/config/#optimizedeps-exclude

[amoutonbrady]

Hi, I was the one responsible for the first integration of Solid and Vite via the vite-plugin-solid.

We did try to exclude those dependencies via the exclude options and it works!

For a little bit of background, early versions of the plugin actually tried to parse the root package.json in the config hook and compute an array of dependencies to be excluded if I detected JSX in their exports. This was quite hacky and error prone as I had to manually resolve the entry point of each dependency.

We have since then moved to a more... common approach where we ask library author to precompile their library AND ship the source in a special export mapping solid. Since we moved to this, working with vite has been a blast. Where I'm worried is when we want to work with SSR. As @ryansolid mentioned, we have special handling and need to compile regarding the target (browser or server).

The parsing issue above is the first of our problem, which we wondered if we missed something or not. The second issue I believe we will encounter is ESBuild... but's out of the scope of this post.

[ryansolid]

The solid mapping is really better to use across the board since it avoids slight compiler version mismatches. I do consider finding a good solution here essential regardless of SSR, so we can consider using Vite as our primary template (and finally lay to rest our messy CRA fork).

It sounds like the parsing error isn't intended so I can write up an issue.

[yyx990803]

I think this should be fixed via 37a103f

[amoutonbrady]

Wow, yeah, looking at it I think it should fix all of our problems!
I'll pull the latest master locally and check it. Thank you for your reactivity!

[amoutonbrady]

I got excited a bit too fast. That commit will be really helpful to us regarding the second part where we would have to try and bypass ESBuild.

However the parsing issue happens before we enter ESBuild real.

I traced it back to here: src/node/optimizer/index.ts#L206 where we are pre-parsing the depencies to get metadata (I assume).

I logged the content of the file to see on which one it was choking, here's the content : https://gist.github.com/amoutonbrady/e0ca61c8907d44b18e3631a3490a9ca8

According to this issue, it seems like es-module-lexer can't parse JSX.

I feel like this might be more of an issue than a discussion at this point. @yyx990803 @matias-capeletto should an issue to keep things going?

[yyx990803]

Do you have a package with .jsx entrypoints?
I think you should file an issue with proper reproduction.

[amoutonbrady]

Yes we do ship JSX as entrypoint (under a export mapping) to be able to do isomorphic work.
I'll do a proper issue. Thanks again!

[ryansolid]

Linking issue for future reference: #2107.

[amoutonbrady]

2.0.2 fixed it! Thank you very much @yyx990803 !