mirror of
https://github.com/cloudflare/vinext.git
synced 2026-05-09 08:25:34 +02:00
[GH-ISSUE #845] App Router build can still reach antd barrel exports despite default optimizePackageImports, causing [plugin rsc:use-client] unsupported ExportAllDeclaration #182
Labels
No labels
enhancement
enhancement
good first issue
help wanted
nextjs-tracking
nextjs-tracking
pull-request
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/vinext#182
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @llc1123 on GitHub (Apr 14, 2026).
Original GitHub issue: https://github.com/cloudflare/vinext/issues/845
Summary
vinext buildfor an App Router project can still fail onantdbarrel exports even thoughantdis in vinext's defaultoptimizePackageImportsset.In my case, the build failed inside
@vitejs/plugin-rscwith:After tracing both vinext and
@vitejs/plugin-rscsource, this looks like a vinext compatibility gap rather than just a raw upstreamplugin-rscbug:experimental.optimizePackageImportsantdvinext:optimize-importsspecifically to avoid RSC-unfriendly barrel import pathsplugin-rscstill reached a client-boundary barrel module containingexport *So the actionable vinext issue seems to be:
Environment
vinext build)@vitejs/plugin-rsc: installed through vinext App Router setupantdExpected behavior
vinext buildshould succeed for a normal App Router project importing components fromantd, especially since:antdis listed in vinext's default optimized package setexperimental.optimizePackageImportsas supported in RSC/SSR environmentsvinext:optimize-importsAt minimum, vinext should rewrite the import chain deeply enough that
plugin-rscdoes not end up analyzing a"use client"barrel module withExportAllDeclaration.Actual behavior
The App Router build reached
antd/es/button/index.js, and@vitejs/plugin-rscfailed with:That failure is thrown by
plugin-rsc's"use client"transform when it seesExportAllDeclarationwhile generating client-reference metadata.Why I believe this is actionable in vinext
I understand the immediate throw site is upstream in
@vitejs/plugin-rsc, but the reason I am filing this in vinext is:experimental.optimizePackageImportsantdin the default optimized package setvinext:optimize-importsplugin intended to avoid exactly this class of RSC/barrel problemsantdusage path still leaks a barrel likeantd/es/button/index.jsintoplugin-rsc, that is still a vinext compatibility gap even if the final throw comes from upstreamIn other words, I am not claiming vinext is the original source of the exception text. I am claiming vinext currently does not fully shield this dependency graph even though it appears intended to.
Root-cause analysis
After reading the vinext, Next.js, and
@vitejs/plugin-rscsources, my current understanding is:1.
plugin-rscdoes not supportExportAllDeclarationin the"use client"client-reference pipelineThe hard failure is in
@vitejs/plugin-rsc:packages/plugin-rsc/src/plugin.tspackages/plugin-rsc/src/transforms/proxy-export.tspackages/plugin-rsc/src/transforms/utils.tspackages/plugin-rsc/src/transforms/wrap-export.tsThe relevant behavior is effectively:
So if
plugin-rscreaches a"use client"barrel module containingexport *, the build fails.2. vinext does try to mitigate this
vinext already has:
vinext:optimize-importsantdThis suggests vinext is already aware of exactly this category of problem.
3. The likely gap is that the rewrite is not deep enough
My understanding is that vinext rewrites top-level source imports such as:
into a more specific subpath import.
However, in this failure mode that still appears to leave a later subpath barrel in the graph, e.g. a path resolving to something like:
If that subpath is itself a
"use client"barrel withexport *, thenplugin-rscstill sees it and throws.So the problem is not that optimizePackageImports is disabled for
antd.The problem seems to be that the current vinext optimization path does not fully eliminate all problematic barrel layers before
plugin-rscanalyzes the module.Related vinext issues / prior work
This report seems closely related to existing vinext work in this area:
My understanding is:
vinext:optimize-importsThis new report appears to be a remaining gap / edge case in the same problem family rather than a completely unrelated bug.
If useful, I can also open a companion upstream issue in
vitejs/vite-plugin-react, because the immediate unsupported AST node is clearly there as well.Repro characteristics
I do not currently have a minimized public reproduction repo prepared yet, but the failure pattern is straightforward:
antdvinext buildantdclient-boundary barrel moduleunsupported ExportAllDeclarationIf a minimal reproduction is required, I can prepare one.
What I think would fix it
Any of these would probably address the issue on the vinext side:
vinext:optimize-importsflattenantdimports more aggressively so the graph does not stop at subpath barrels likeantd/es/buttonantdbarrel chains in App Router RSC buildsplugin-rscsupportsExportAllDeclarationAdditional context
I realize this may ultimately require an upstream fix in
@vitejs/plugin-rsc, but from a user perspective:antdis default-optimizedantdbarrel exportThat makes this worth tracking in vinext as a compatibility bug, even if the final long-term fix is shared with upstream.
Thanks — happy to provide a minimal reproduction if that helps.