Remove clientReferenceDedupPlugin

[hyoban]

I roughly understand that #413 aims to resolve #409, but I think it might introduce more problems.
It assumes that pkg/dist/Button.js can always originate from pkg, but the current ESM packages likely don't work that way. Taking fumadocs-ui as an example, it doesn't even have an entry point for fumadocs-ui; all exports are subpaths. In this case, this plugin will produce even more confusing errors.

Plugin: builtin:vite-resolve (x2)
9:34:04 PM [vite+] Internal server error: "." is not exported under the conditions ["module", "browser", "development", "import"] from package /Users/hyoban/f/vinext/examples/fumadocs-docs-template/node_modules/fumadocs-ui (see exports field in /Users/hyoban/f/vinext/examples/fumadocs-docs-template/node_modules/fumadocs-ui/package.json)

I tried some approaches in #577, reverse-match file path to exports. But when dealing with files not defined in exports, such as dist/layouts/docs/client.js, we can only optimize them as individual deps. I feel like doing so might be heading in the wrong direction.

I noticed that both fumadocs and waku are recommending adding deps to optimizeDeps:

https://github.com/fuma-nama/fumadocs/blob/aa7e96a46521f2e7953e094eaa19f49c3cf7540f/examples/waku/waku.config.ts#L10-L16

https://github.com/wakujs/waku/blob/da6fbb4f83fb0eed12188a4a53b29c230275af9c/examples/42_react-tweet/waku.config.ts#L7-L10

I think this issue would be better addressed within @vitejs/plugin-rsc, such as in vitejs/vite-plugin-react#759 and vitejs/vite-plugin-react#775.

Please let me know if I have made any mistakes.

[james-elicx]

Totally agree that architecturally it would make more sense long-term for this to be addressed in Vite's RSC plugin.

Regarding #433, it sounds like we might be able to do a better job of scoping that to where we can guarantee / assert that a relevant subpath export exists to re-map it to, and if not, fall back to the original path. It sounds like that might be along the lines of what you were trying out?

I feel like we might end up in a bit of a middle-ground where the plugin only handles certain scenarios that it can figure out until this is better handled upstream, or leave people to use optimizeDeps.exclude.

Would be interested to hear what others think!

cc @hi-ogawa as you might have some thoughts on this.

[hi-ogawa]

The issue and analysis described in #409 looks correct and that's partly an expected behavior / limitation. It's also likely correct that the attempt by #413 is also not sound as you identified package's internal client component access via relative path ./dist/... are not often the public package exports. This fundamental problem statement is also presented in my old https://github.com/hi-ogawa/rsc-tests:

Notably it's not possible to optimize the 3rd case (client in server package) since Vite's deps optimization works based on package exports entries.

Thus, what @vitejs/plugin-rsc does out-of-the-box is to automatically detect the case of #409 and warn the users to manually configure optimizeDeps.exclude. I haven't come up with other directions of solutions.
(Note that the issue vitejs/vite-plugin-react#759 is about false-positive and false-negative of such auto detection + warning. It's not about solving the fundamental issue.)