Optimize next-app-loader resolving speed

[timneutkens]

What?

We recently implemented an optimized resolving method for app in Turbopack, this ports some of the main changes in that resolving logic to optimize next-app-loader which during compilation resolves the tree structure that we use to render in app-render.tsx.

Here's the results for a page that is nested a few levels deep on vercel.com using App Router. These results only cover next-app-loader, not any modules compiled below it.

Before

After

Raw numbers

Before	After	Delta	Delta (percent)
1.620 ms	76.39 ms	-1.543.61 ms	-95.2%

How?

Changed the resolving logic to use fileExists, looping over the provided pageExtensions.
For Turbopack we have a process that does only one pass for generating all trees. That also only reads directories instead of checking individual files, which is even better (<5ms for generating all possible trees) but this PR is a quick win that has a big impact already without refactoring the entire entries generation in webpack.

[timneutkens]

Current dependencies on/for this PR:

• canary
  • PR Optimize next-app-loader resolving speed #50745 👈

This comment was auto-generated by Graphite.

[ijjk]

Failing test suites

Commit: 08e0d63

pnpm testheadless test/development/basic/node-builtins.test.ts

• node builtins > should have polyfilled node.js builtins for the browser correctly in client component

Expand output

● node builtins › should have polyfilled node.js builtins for the browser correctly in client component

page.waitForFunction: Timeout 60000ms exceeded.

  362 |   waitForCondition(condition, timeout) {
  363 |     return this.chain(() => {
> 364 |       return page.waitForFunction(condition, { timeout })
      |                   ^
  365 |     })
  366 |   }
  367 |

  at lib/browsers/playwright.ts:364:19

Read more about building and testing Next.js in contributing.md.