App router doesn't work when using pageExtensions config for Pages router

[TCezarRod]

Verify canary release

• I verified that the issue exists in the latest Next.js canary release

Provide environment information

Operating System:
      Platform: linux
      Arch: x64
      Version: #22 SMP Tue Jan 10 18:39:00 UTC 2023
    Binaries:
      Node: 16.17.0
      npm: 8.15.0
      Yarn: 1.22.19
      pnpm: 7.1.0
    Relevant packages:
      next: 13.4.7-canary.1
      eslint-config-next: N/A
      react: 18.2.0
      react-dom: 18.2.0
      typescript: 4.9.5

Which area(s) of Next.js are affected? (leave empty if unsure)

App directory (appDir: true)

Link to the code that reproduces this issue or a replay of the bug

https://codesandbox.io/p/sandbox/laughing-booth-7z2m98?file=%2Fnext.config.js%3A1%2C1

To Reproduce

• Create a new Next.js application
• Enable the pageExtensions option in next.config.js to add a custom extension, as in the pages router docs. Any extension can be used, e.g. custom.tsx
• Add any page to your pages directory, using the configured extension to verify the router is working. E.g. pages/mypage.custom.tsx
• Add the app directory and create a new page, e.g. app/myotherpage/page.tsx
  • Verify the app pages are not working 🐛

Going further:

• Try renaming the new page in the app directory to use the custom extension
  • E.g. rename app/myotherpage/page.tsx to app/myotherpage/page.custom.tsx
• Verify that, instead of a 404 page, the error pageExtensions.map is not a function is triggered

Describe the Bug

Pages in the app directory are not recognised if the pageExtensions config is being used. Trying to access them render a 404 error page.

Attempting to rename the app page to use the same custom extension set for the pages router in the pageExtensions config (e.g. app/myotherpage/page.custom.tsx) results in the error pageExtensions.map is not a function.

Disabling the pageExtensions config and renaming the pages router pages to remove the custom extensions is a workaround that allows both routers to coexist as expected. In a real legacy app that would probably require the entire pages directory to be refactored

Expected Behavior

The app router pages should be able to coexist with the pageExtensions option enabled to allow a smoother gradual migration (as recommended by the docs) of legacy apps that still heavily rely on custom pages extensions.

Which browser are you using? (if relevant)

No response

How are you deploying your application? (if relevant)

No response

[OzzieOrca]

Just realized this is why my migration to the app directory was always returning 404s or the old page. I'd tried it a couple times over a few months and given up before but finally commented out my pageExtensions and things started working. Thanks.

I have this in my next.config.js:

  pageExtensions: [
    'page.tsx',
    'page.ts',
    'page.jsx',
    'page.js',
    'page.md',
    'page.mdx',
  ],

Creating app/layout.page.tsx and app/page.page.tsx seems to work for me now and I'll start migrating with that pattern. Guess I can't drop the custom page extensions until I'm done.

Seems like the file extensions config for searching for app directory files should be a different config key than the .page.tsx config to differentiate pages from other files in the page directory. Now that that page differentiating is built into the app router using the filename, not the extension, this custom pageExtensions config shouldn't be needed but it makes migrating weird.

[jelling]

Any plans to address this? If not, please update the docs so they don't give the impression that pageExtensions works for the app router.

[zigang93]

I am hoping have flag to exclude pageExtensions for app router when migrating from page folder

[ajwootto]

Ran into this as well, it's a big pitfall during migration since it's not mentioned in the migration guide, and is definitely an unexpected side-effect of having that setting. I don't think anyone would really want that setting to apply to app router, since the only reason it was necessary before is because the pages router treated every file as a route unless that setting was set. Now that we have magic filenames like page.tsx this setting doesn't really make sense

[vdanchenkov]

Just want to note that we are on next@14, we use app router, no pages. We actively use pageExtensions and having no issues with it. And this setting is essential for us.

It's the only way we found to replace/remove pages from build based on env settings.

[robahtou]

@vdanchenkov can you share an example config that works for you? Trying to do the same but can't get it to work.

[devakrishna33]

The error

pageExtensions.map is not a function

occurs only if you have a single entry in pageExtensions
to fix it you can add multiple entries like,

  pageExtensions: ["page.tsx", "placeholder.tsx"]

Hopefully the issue will be fixed once this PR is merged