[GH-ISSUE #845] App Router build can still reach antd barrel exports despite default optimizePackageImports, causing [plugin rsc:use-client] unsupported ExportAllDeclaration #182

Open
opened 2026-05-06 12:37:56 +02:00 by BreizhHardware · 0 comments

Originally created by @llc1123 on GitHub (Apr 14, 2026).
Original GitHub issue: https://github.com/cloudflare/vinext/issues/845

Summary

vinext build for an App Router project can still fail on antd barrel exports even though antd is in vinext's default optimizePackageImports set.

In my case, the build failed inside @vitejs/plugin-rsc with:

[plugin rsc:use-client] .../node_modules/antd/es/button/index.js
Error: unsupported ExportAllDeclaration

After tracing both vinext and @vitejs/plugin-rsc source, this looks like a vinext compatibility gap rather than just a raw upstream plugin-rsc bug:

  • vinext already claims support for experimental.optimizePackageImports
  • vinext's default optimized package list already includes antd
  • vinext already introduced vinext:optimize-imports specifically to avoid RSC-unfriendly barrel import paths
  • but in this case the import optimization did not fully shield the dependency chain, and plugin-rsc still reached a client-boundary barrel module containing export *

So the actionable vinext issue seems to be:

the current optimize-imports path is not sufficient to prevent some antd subpath barrels from leaking into the App Router RSC pipeline.


Environment

  • Framework mode: App Router
  • Build phase: production build (vinext build)
  • Package manager: npm
  • React: 19.x
  • vinext: current release at the time of testing
  • Vite: 8.x
  • @vitejs/plugin-rsc: installed through vinext App Router setup
  • UI library: antd

Expected behavior

vinext build should succeed for a normal App Router project importing components from antd, especially since:

  • antd is listed in vinext's default optimized package set
  • vinext documents experimental.optimizePackageImports as supported in RSC/SSR environments
  • this class of barrel-import problem was already addressed by vinext:optimize-imports

At minimum, vinext should rewrite the import chain deeply enough that plugin-rsc does not end up analyzing a "use client" barrel module with ExportAllDeclaration.


Actual behavior

The App Router build reached antd/es/button/index.js, and @vitejs/plugin-rsc failed with:

Error: unsupported ExportAllDeclaration

That failure is thrown by plugin-rsc's "use client" transform when it sees ExportAllDeclaration while 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:

  1. vinext explicitly advertises support for experimental.optimizePackageImports
  2. vinext includes antd in the default optimized package set
  3. vinext already has a dedicated vinext:optimize-imports plugin intended to avoid exactly this class of RSC/barrel problems
  4. therefore, if a standard antd usage path still leaks a barrel like antd/es/button/index.js into plugin-rsc, that is still a vinext compatibility gap even if the final throw comes from upstream

In 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-rsc sources, my current understanding is:

1. plugin-rsc does not support ExportAllDeclaration in the "use client" client-reference pipeline

The hard failure is in @vitejs/plugin-rsc:

  • packages/plugin-rsc/src/plugin.ts
  • packages/plugin-rsc/src/transforms/proxy-export.ts
  • packages/plugin-rsc/src/transforms/utils.ts
  • packages/plugin-rsc/src/transforms/wrap-export.ts

The relevant behavior is effectively:

if (node.type === 'ExportAllDeclaration') {
  throw new Error('unsupported ExportAllDeclaration')
}

So if plugin-rsc reaches a "use client" barrel module containing export *, the build fails.

2. vinext does try to mitigate this

vinext already has:

  • vinext:optimize-imports
  • a default optimized package list that includes antd
  • documentation stating barrel imports are rewritten to direct sub-module imports in RSC/SSR environments

This 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:

import { Button } from 'antd'

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:

antd/es/button/index.js

If that subpath is itself a "use client" barrel with export *, then plugin-rsc still 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-rsc analyzes the module.


This report seems closely related to existing vinext work in this area:

My understanding is:

  • #100 reported barrel-import-related RSC failures
  • #137 proposed a vinext-side optimization approach
  • #138 implemented vinext:optimize-imports

This 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:

  1. Start with a vinext App Router project
  2. Use antd
  3. Build with vinext build
  4. The RSC pipeline eventually reaches an antd client-boundary barrel module
  5. Build fails with unsupported ExportAllDeclaration

If 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:

  1. Make vinext:optimize-imports flatten antd imports more aggressively so the graph does not stop at subpath barrels like antd/es/button
  2. Add additional package-specific handling for antd barrel chains in App Router RSC builds
  3. Ensure the rewritten path lands on the concrete implementation module rather than a secondary barrel
  4. Otherwise document this as a known gap and recommend a temporary workaround until upstream plugin-rsc supports ExportAllDeclaration

Additional context

I realize this may ultimately require an upstream fix in @vitejs/plugin-rsc, but from a user perspective:

  • vinext claims antd is default-optimized
  • vinext claims barrel imports are rewritten in RSC/SSR
  • App Router build still fails on an antd barrel export

That 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.

Originally created by @llc1123 on GitHub (Apr 14, 2026). Original GitHub issue: https://github.com/cloudflare/vinext/issues/845 ### Summary `vinext build` for an App Router project can still fail on `antd` barrel exports even though `antd` is in vinext's default `optimizePackageImports` set. In my case, the build failed inside `@vitejs/plugin-rsc` with: ```txt [plugin rsc:use-client] .../node_modules/antd/es/button/index.js Error: unsupported ExportAllDeclaration ``` After tracing both vinext and `@vitejs/plugin-rsc` source, this looks like a vinext compatibility gap rather than just a raw upstream `plugin-rsc` bug: - vinext already claims support for `experimental.optimizePackageImports` - vinext's default optimized package list already includes `antd` - vinext already introduced `vinext:optimize-imports` specifically to avoid RSC-unfriendly barrel import paths - but in this case the import optimization did not fully shield the dependency chain, and `plugin-rsc` still reached a client-boundary barrel module containing `export *` So the actionable vinext issue seems to be: > the current optimize-imports path is not sufficient to prevent some `antd` subpath barrels from leaking into the App Router RSC pipeline. --- ### Environment - Framework mode: App Router - Build phase: production build (`vinext build`) - Package manager: npm - React: 19.x - vinext: current release at the time of testing - Vite: 8.x - `@vitejs/plugin-rsc`: installed through vinext App Router setup - UI library: `antd` --- ### Expected behavior `vinext build` should succeed for a normal App Router project importing components from `antd`, especially since: - `antd` is listed in vinext's default optimized package set - vinext documents `experimental.optimizePackageImports` as supported in RSC/SSR environments - this class of barrel-import problem was already addressed by `vinext:optimize-imports` At minimum, vinext should rewrite the import chain deeply enough that `plugin-rsc` does not end up analyzing a `"use client"` barrel module with `ExportAllDeclaration`. --- ### Actual behavior The App Router build reached `antd/es/button/index.js`, and `@vitejs/plugin-rsc` failed with: ```txt Error: unsupported ExportAllDeclaration ``` That failure is thrown by `plugin-rsc`'s `"use client"` transform when it sees `ExportAllDeclaration` while 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: 1. vinext explicitly advertises support for `experimental.optimizePackageImports` 2. vinext includes `antd` in the default optimized package set 3. vinext already has a dedicated `vinext:optimize-imports` plugin intended to avoid exactly this class of RSC/barrel problems 4. therefore, if a standard `antd` usage path still leaks a barrel like `antd/es/button/index.js` into `plugin-rsc`, that is still a vinext compatibility gap even if the final throw comes from upstream In 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-rsc` sources, my current understanding is: #### 1. `plugin-rsc` does not support `ExportAllDeclaration` in the `"use client"` client-reference pipeline The hard failure is in `@vitejs/plugin-rsc`: - `packages/plugin-rsc/src/plugin.ts` - `packages/plugin-rsc/src/transforms/proxy-export.ts` - `packages/plugin-rsc/src/transforms/utils.ts` - `packages/plugin-rsc/src/transforms/wrap-export.ts` The relevant behavior is effectively: ```ts if (node.type === 'ExportAllDeclaration') { throw new Error('unsupported ExportAllDeclaration') } ``` So if `plugin-rsc` reaches a `"use client"` barrel module containing `export *`, the build fails. #### 2. vinext does try to mitigate this vinext already has: - `vinext:optimize-imports` - a default optimized package list that includes `antd` - documentation stating barrel imports are rewritten to direct sub-module imports in RSC/SSR environments This 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: ```ts import { Button } from 'antd' ``` 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: ```txt antd/es/button/index.js ``` If that subpath is itself a `"use client"` barrel with `export *`, then `plugin-rsc` still 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-rsc` analyzes the module. --- ### Related vinext issues / prior work This report seems closely related to existing vinext work in this area: - #100 - #137 - #138 My understanding is: - #100 reported barrel-import-related RSC failures - #137 proposed a vinext-side optimization approach - #138 implemented `vinext:optimize-imports` This 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: 1. Start with a vinext App Router project 2. Use `antd` 3. Build with `vinext build` 4. The RSC pipeline eventually reaches an `antd` client-boundary barrel module 5. Build fails with `unsupported ExportAllDeclaration` If 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: 1. Make `vinext:optimize-imports` flatten `antd` imports more aggressively so the graph does not stop at subpath barrels like `antd/es/button` 2. Add additional package-specific handling for `antd` barrel chains in App Router RSC builds 3. Ensure the rewritten path lands on the concrete implementation module rather than a secondary barrel 4. Otherwise document this as a known gap and recommend a temporary workaround until upstream `plugin-rsc` supports `ExportAllDeclaration` --- ### Additional context I realize this may ultimately require an upstream fix in `@vitejs/plugin-rsc`, but from a user perspective: - vinext claims `antd` is default-optimized - vinext claims barrel imports are rewritten in RSC/SSR - App Router build still fails on an `antd` barrel export That 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.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/vinext#182
No description provided.