Repository navigation
fix(vite): recognize aliased default exports in link checks - #11567
NathanWalker merged 2 commits into
Conversation
|
View your CI Pipeline Execution ↗ for commit 7c875e8
💡 Verify your cache is correct by running tasks in a sandbox. Read docs ↗ ☁️ Nx Cloud last updated this comment at |
commit: |
|
A possible follow-up is to use This PR reuses the existing Babel dependency to keep the correctness fix focused. Before switching, we should benchmark representative transformed modules, run the regression cases against the chosen lexer version (including aliases, quoted names, namespace re-exports, and type-only exports), and account for its initialization requirements. If target parsing is a meaningful dev-server cost, the lexer could be a useful optimization. |
…st unparseable targets
PR Checklist
What is the current behavior?
The native dev module server rejects valid defaults such as
export { named as default }, while comments and strings containingexport defaultcan bypass validation.What is the new behavior?
Use the existing Babel parser to inspect export declarations and specifiers, including aliases, quoted names, and namespace re-exports. Missing runtime defaults remain rejected; CommonJS handling is preserved. Adds 18 route-handler regression tests, including revalidation when a target gains or loses its default.
Validation: eight new tests fail before the fix; all 18 pass afterward.
npx nx run vite:buildpasses. The fullvite:testrun passes 1,912 tests and fails fivetypescript-optional.spec.tscases withThe "paths[1]" argument must be of type string. Received undefined; the same five fail with unchanged upstream production source in this worktree. No device startup or HMR verification.Fixes #11566.