vercel
"Overly broad patterns" warnings during build
Hello,
after upgrading our application to next.js 16 we see lots of build warnings from turbopack for a server action which handles file uploads. This only seems to happen when a certain amount of files exists and path.join() or path.resolve() is used.
Is there a way to either fix these warnings, supress them or is it simply a case of not being best practices and files should be somewhere else?
Edit 2025-10-28: The problem remains with version 16.0.1.
Link to the code that reproduces this issue
https://github.com/MarcJose/nextjs16-turbopack
To Reproduce
The example project reproduces this warning by creating a certain amount of dummy files in the project as postinstall and having a server action to get the path of a file at runtime.
Current vs. Expected behavior
Current:
> [email protected] build
> next build
▲ Next.js 16.0.0 (Turbopack)
Creating an optimized production build ...
Turbopack build encountered 2 warnings:
./src/actions/files.ts:32:24
The file pattern ('/ROOT/public/' <dynamic> '/' <dynamic> | '/ROOT/public' <dynamic> '/' <dynamic> | '/ROOT/public/' <dynamic> | '/ROOT/public' <dynamic>) matches 16000 files in [project]/
30 |
31 | // This also triggers the warning
> 32 | const resolvedPath = path.resolve(
| ^^^^^^^^^^^^^
> 33 | baseDir,
| ^^^^^^^^^^^^
> 34 | userPath.replace(/^\//, ""),
| ^^^^^^^^^^^^
> 35 | fileName
| ^^^^^^^^^^^^
> 36 | );
| ^^^^
37 |
38 | return resolvedPath;
39 | }
Overly broad patterns can lead to build performance issues and over bundling.
Import trace:
Server Component:
./src/actions/files.ts
./src/app/page.tsx
./src/actions/files.ts:20:22
The file pattern ('/ROOT/public/media/' <dynamic> '/' <dynamic> | '/ROOT/public/media' <dynamic> '/' <dynamic> | '/ROOT/public/media/' <dynamic> | '/ROOT/public/media' <dynamic>) matches 32000 files in [project]/
18 | // This line triggers the warning:
19 | // "The file pattern matches X files... Overly broad patterns can lead to build performance issues"
> 20 | const targetPath = path.join(mediaDir, folder, filename);
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
21 |
22 | return targetPath;
23 | }
Overly broad patterns can lead to build performance issues and over bundling.
Import trace:
Server Component:
./src/actions/files.ts
./src/app/page.tsx
✓ Compiled successfully in 862.8ms
✓ Finished TypeScript in 650.1ms
✓ Collecting page data in 162.0ms
✓ Generating static pages (3/3) in 214.6ms
✓ Finalizing page optimization in 3.7ms
Route (app)
┌ ○ /
└ ○ /_not-found
○ (Static) prerendered as static content
Expected:
Clean build.
Provide environment information
Operating System:
Platform: linux
Arch: x64
Version: #1 SMP PREEMPT_DYNAMIC Sun, 19 Oct 2025 19:21:18 +0000
Available memory (MB): 61858
Available CPU cores: 16
Binaries:
Node: 22.20.0
npm: 10.9.3
Yarn: N/A
pnpm: N/A
Relevant Packages:
next: 16.0.0 // Latest available version is detected (16.0.0).
eslint-config-next: N/A
react: 19.2.0
react-dom: 19.2.0
typescript: 5.9.3
Next.js Config:
output: N/A
Which area(s) are affected? (Select all that apply)
Turbopack
Which stage(s) are affected? (Select all that apply)
next build (local)
Additional context
No response
I’m running into this as well, and weirdly, there aren’t actually that many files in the source directory. It claims to match 27742 files, but there are only 814 files in the relevant directory, and even fewer that match the actual import pattern. I’ll include the full logs below in case it’s helpful, but really I’m just trying to +1 this issue, to find a way to suppress this warning.
Logs and code
Here’s the code:
const ROOT_CONTENT_PATH = path.join(process.cwd(), '/content');
export async function getAllLessonPaths(courseSlug) {
const courseRootPath = path.join(
ROOT_CONTENT_PATH,
`/${courseSlug}`
);
const moduleSlugs = getDirectories(courseRootPath);
let lessonPaths = [];
for (const moduleSlug of moduleSlugs) {
const moduleRootPath = path.join(
ROOT_CONTENT_PATH,
`/${courseSlug}/${moduleSlug}`
);
const lessonFilenames = fs
.readdirSync(moduleRootPath)
.filter(
(filename) =>
/\.mdx$/.test(filename) && filename !== 'index.mdx'
)
.map((filename) => ({
moduleMetadata,
moduleSlug,
lessonSlug: filename.replace(/\.mdx$/, ''),
lessonPath: path.join(
ROOT_CONTENT_PATH,
`/${courseSlug}/${moduleSlug}/${filename}`
),
}));
lessonPaths.push(...lessonFilenames);
}
return lessonPaths;
}
And here’s the logs, claiming that there are way more files than actually exist:
The file pattern ('/ROOT/content//' <dynamic> '/' <dynamic> '/' <dynamic> | '/ROOT/content/' <dynamic> '/' <dynamic> '/' <dynamic>) matches 16330 files in [project]/
44 | moduleSlug,
45 | lessonSlug: filename.replace(/\.mdx$/, ''),
> 46 | lessonPath: path.join(
| ^^^^^^^^^^
> 47 | ROOT_CONTENT_PATH,
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 48 | `/${courseSlug}/${moduleSlug}/${filename}`
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 49 | ),
| ^^^^^^^^^^
50 | }));
51 |
52 | lessonPaths.push(...lessonFilenames);
Overly broad patterns can lead to build performance issues and over bundling.
./content/content.helpers.js:157:22
The file pattern ('/ROOT/content//' <dynamic> '/' <dynamic> '//' <dynamic> | '/ROOT/content/' <dynamic> '/' <dynamic> '//' <dynamic> | '/ROOT/content//' <dynamic> '/' <dynamic> '/' <dynamic> | '/ROOT/content/' <dynamic> '/' <dynamic> '/' <dynamic>) matches 27742 files in [project]/
155 | const lessons = [];
156 | for (const filename of lessonFilenames) {
> 157 | const filePath = path.join(moduleUrl, `/${filename}`);
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
158 | const slug = filename.replace('.mdx', '');
159 |
160 | const data = await getFrontmatterForFile(filePath);
Overly broad patterns can lead to build performance issues and over bundling.
I don't even understand what this check is for. In our case, we have a bunch of files in a local directory that can be read via an API route, and of course that path is dynamic, including the base directory which can be set via an environment variable. Does it really look through my files at build time and would it try to bundle some of the files? That doesn't make sense as the directory will be mounted into the container at runtime. So yes, I would like to suppress the warning, but also avoid potentially expensive checks for something irrelevant.
In my case I am intentionally bundling the data, this is specifically for country data, it does have a ton of files within folders per county and nested there per state (for countries that have states, some don't and only have cities).
I do tell Next specifically I want that bundled, maybe it's a bad pattern but I can't think of a simpler pattern to make it so you can request only the data relevant to the search query:
const nextConfig: NextConfig = {
outputFileTracingIncludes: {
'/api/location/countries': ['./src/lib/data/countries-states-cities/**/*'],
'/api/location/states': ['./src/lib/data/countries-states-cities/**/*'],
'/api/location/cities': ['./src/lib/data/countries-states-cities/**/*'],
},
...
+1 for this, for me it's flaring up even when used in "use server"; files :/
no idea how to turn it off but i have the same use case, reading off some files from a local directory and using path.resolve(process.cwd(), ...) or path.resolve(__dirname, ...)
+1 for this, for me it's flaring up even when used in
"use server";files :/ no idea how to turn it off but i have the same use case, reading off some files from a local directory and usingpath.resolve(process.cwd(), ...)orpath.resolve(__dirname, ...)
Here you go, in my case I shut off errors coming from that folder but you can go more specific:
// next.config.ts
// Ignore Turbopack errors with countries-states-cities data big list of files
const originalStdErrWrite = process.stderr.write.bind(process.stderr);
process.stderr.write = ((chunk, encoding, callback) => {
if (chunk.toString().includes('countries-states-cities')) {
return true;
}
return originalStdErrWrite(chunk, encoding, callback);
}) as typeof process.stderr.write;
Still having this issue at 16.0.7
Edit by maintainer bot: Comment was automatically minimized because it was considered unhelpful. (If you think this was by mistake, let us know). Please only comment if it adds context to the issue. If you want to express that you have the same problem, use the upvote 👍 on the issue description or subscribe to the issue for updates. Thanks!
In the most recent version I cannot see the issue anymore so it seems to be solved :)