Next.js change
Next.js scoped its App Router file-convention export validation to files that live inside the app directory. Previously the SWC RSC validator matched App Router conventions (page, layout, route, sitemap, robots, manifest, icon, opengraph-image, etc.) purely by filename, so a Pages Router file like pages/sitemap.js or pages/robots.js that exported getStaticProps/getServerSideProps incorrectly failed the build with "getStaticProps" is not supported in app/. (regression introduced in 16.3.0 by #94962). The fix gates all App-entry checks (and the client-import error message) on a new is_in_app_dir() helper, and also fixes the client-import "server-only API" message to distinguish Pages vs Client Component context.
Commits: cdf5c37
Next.js files changed: crates/next-custom-transforms/src/transforms/react_server_components.rs, test/e2e/pages-app-router-filenames/
Why this matters to vinext
vinext scans both pages/ and app/ and applies its own routing + convention detection (packages/vinext/src/routing/pages-router.ts, packages/vinext/src/routing/app-router.ts). If vinext treats a file named sitemap/robots/manifest/icon/opengraph-image/twitter-image as a metadata/App Router convention based on filename alone, it will mis-handle those files when they live under pages/ — where they are ordinary Pages routes (pages/sitemap.js is a page, not a metadata route). App Router metadata-convention handling and any export-validation must be gated on the file being inside the app directory.
Priority
Important
Suggested action
- Investigate: confirm whether vinext's
pages/ scanner or metadata-convention detection matches sitemap/robots/manifest/icon/opengraph-image/twitter-image by basename regardless of directory. If so, gate that detection on the app directory (mirror is_in_app_dir) so Pages Router files with those names are treated as normal pages and may export getStaticProps/getServerSideProps. Add a fixture with pages/sitemap.js + getStaticProps.
Next.js change
Next.js scoped its App Router file-convention export validation to files that live inside the app directory. Previously the SWC RSC validator matched App Router conventions (
page,layout,route,sitemap,robots,manifest,icon,opengraph-image, etc.) purely by filename, so a Pages Router file likepages/sitemap.jsorpages/robots.jsthat exportedgetStaticProps/getServerSidePropsincorrectly failed the build with"getStaticProps" is not supported in app/.(regression introduced in 16.3.0 by #94962). The fix gates all App-entry checks (and the client-import error message) on a newis_in_app_dir()helper, and also fixes the client-import "server-only API" message to distinguish Pages vs Client Component context.Commits: cdf5c37
Next.js files changed:
crates/next-custom-transforms/src/transforms/react_server_components.rs,test/e2e/pages-app-router-filenames/Why this matters to vinext
vinext scans both
pages/andapp/and applies its own routing + convention detection (packages/vinext/src/routing/pages-router.ts,packages/vinext/src/routing/app-router.ts). If vinext treats a file namedsitemap/robots/manifest/icon/opengraph-image/twitter-imageas a metadata/App Router convention based on filename alone, it will mis-handle those files when they live underpages/— where they are ordinary Pages routes (pages/sitemap.jsis a page, not a metadata route). App Router metadata-convention handling and any export-validation must be gated on the file being inside the app directory.Priority
Important
Suggested action
pages/scanner or metadata-convention detection matchessitemap/robots/manifest/icon/opengraph-image/twitter-imageby basename regardless of directory. If so, gate that detection on the app directory (mirroris_in_app_dir) so Pages Router files with those names are treated as normal pages and may exportgetStaticProps/getServerSideProps. Add a fixture withpages/sitemap.js+getStaticProps.