Improve build report route analysis with AST parsing

[Boyeep]

Fixes #605

1. Summary

This replaces the build report’s regex/string-based route analysis with AST-based analysis using the TypeScript compiler API.

The main goal is to make route classification more accurate, especially around getStaticProps and exported route config, while keeping the existing report flow intact.

2. What changed

• Switched build-report source inspection in packages/vinext/src/build/report.ts to TypeScript AST parsing

• Replaced regex-based detection for:

• named exports

• export const dynamic = ...

• export const revalidate = ...

• getStaticProps revalidate extraction

• Reused a single parsed AST per file during route classification instead of reparsing for each helper

• Added support for:

• aliased exports

• local identifier aliases

• as const

• satisfies

• extension-aware TS vs TSX parsing

• Ignored non-runtime exports:

• export type { ... }

• export { type ... }

• export declare ...

• Treated non-local or non-analyzable getStaticProps exports conservatively as unknown instead of incorrectly reporting static

• Applied speculative prerender promotion to Pages routes as well, so Pages routes classified as unknown can still be upgraded to static when prerender confirms them

3. Tests

Added regression coverage for:

• early-return redirects
• re-exports
• imported re-exports
• aliased exports
• default exports
• type-only exports
• generic arrow getStaticProps
• local identifier aliases
• non-analyzable local getStaticProps factories
• as const / satisfies
• speculative prerender upgrade for Pages routes

vp test tests/build-report.test.ts passes with 107 tests.

4. Notes

vp lint still reports the existing unrelated benchmark import errors:

benchmarks/vinext/vite.config.ts
benchmarks/vinext-rolldown/vite.config.ts

[pkg-pr-new]

Open in StackBlitz

npm i https://pkg.pr.new/vinext@606

commit: 536d7e2

[james-elicx]

Sorry to be a pain - have you looked at oxc-parser before?

It might be a nice option to try out as it has great performance and compatibility - https://npmx.dev/package/oxc-parser

[Boyeep]

oxc-parser actually does seem like a strong option here.

For this PR, I’d prefer to keep the current TypeScript compiler API approach so the scope stays limited to improving report accuracy and landing the current follow-up fixes cleanly. But I agree Oxc looks like a very reasonable option for the longer-term parser-based follow-up, and I’d be happy to explore that in a separate PR.

[james-elicx]

Completely slipped my mind before - Vite also has a parseAst function as well which we use in several places already

[Boyeep]

Yeah, that makes sense probably worth checking first.