[GH-ISSUE #581] Remove clientReferenceDedupPlugin #126

New issue

Open

opened 2026-05-06 12:37:25 +02:00 by BreizhHardware · 2 comments

BreizhHardware commented

2026-05-06 12:37:25 +02:00

Owner

Originally created by @hyoban on GitHub (Mar 18, 2026).
Original GitHub issue: https://github.com/cloudflare/vinext/issues/581

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:

github.com/fuma-nama/fumadocs@aa7e96a465/examples/waku/waku.config.ts (L10-L16)

github.com/wakujs/waku@da6fbb4f83/examples/42_react-tweet/waku.config.ts (L7-L10)

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

Please let me know if I have made any mistakes.

Originally created by @hyoban on GitHub (Mar 18, 2026). Original GitHub issue: https://github.com/cloudflare/vinext/issues/581 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 https://github.com/vitejs/vite-plugin-react/issues/759 and https://github.com/vitejs/vite-plugin-react/issues/775. Please let me know if I have made any mistakes.

BreizhHardware commented

2026-05-06 12:37:26 +02:00

Author

Owner

@james-elicx commented on GitHub (Mar 18, 2026):

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.

@james-elicx commented on GitHub (Mar 18, 2026): 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.

BreizhHardware commented

2026-05-06 12:37:26 +02:00

Author

Owner

@hi-ogawa commented on GitHub (Mar 18, 2026):

The issue and analysis described in https://github.com/cloudflare/vinext/issues/409 looks correct and that's partly an expected behavior / limitation. It's also likely correct that the attempt by https://github.com/cloudflare/vinext/pull/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 https://github.com/cloudflare/vinext/issues/409 and warn the users to manually configure optimizeDeps.exclude. I haven't come up with other directions of solutions.
(Note that the issue https://github.com/vitejs/vite-plugin-react/issues/759 is about false-positive and false-negative of such auto detection + warning. It's not about solving the fundamental issue.)

@hi-ogawa commented on GitHub (Mar 18, 2026): The issue and analysis described in https://github.com/cloudflare/vinext/issues/409 looks correct and that's partly an expected behavior / limitation. It's also likely correct that the attempt by https://github.com/cloudflare/vinext/pull/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 https://github.com/cloudflare/vinext/issues/409 and warn the users to manually configure `optimizeDeps.exclude`. I haven't come up with other directions of solutions. (Note that the issue https://github.com/vitejs/vite-plugin-react/issues/759 is about false-positive and false-negative of such auto detection + warning. It's not about solving the fundamental issue.)