Expectations and Edge Cases for next.config.ts

[devjiwonchoi]

Hello engineers, #57656 is close to the end of being shipped(I wish), and would like to hear about your expectations, edge cases, or concerns.

The PR is covering the following cases:

• config as an async function
• export { x as default }
• import alias (tsconfig baseUrl and paths)
• import from node_modules
• use Node.js API (fs, path, etc.)
• nested imports (config -> A -> B)

Native ESM (package.json type: module)

• importing .cts
• importing .cjs
• importing .js (ESM)

CJS

• importing Native ESM packages --> use next.config.mts
• importing .mts
• importing .mjs
• importing .js (CJS)

Feel free to suggest any missing cases you expect to be covered, I hope we can ship it to handle most cases!

Below are the questions I'd like to know to improve current behavior:

1. What is the maximum amount of time you can accept for the separate compilation step required by next.config.ts support?
2. If the output directory of the compiled config is fixed to .next, how much would it negatively affect your DX?
3. Do you think you need a .cts extension for config? If so, what are the use cases that you need and why?