docs(config): update next.config examples to ESM and add TS #84017
What? This PR updates all next.config.js code examples within the App Router API reference to use modern syntax. The changes convert the examples from CommonJS to ESM (.mjs) and add a corresponding TypeScript (.ts) version with an interactive toggle.
Why? The existing documentation used outdated CommonJS (module.exports) syntax, while the official Next.js recommendation is to use ESM (export default). Additionally, the code examples lacked TypeScript versions and proper line highlighting, which are crucial for developer experience. This change brings the documentation in line with modern best practices.
How? Iterated through all .mdx files in the /docs/app/api-reference/config/next-config-js/ directory.
Replaced the old single code block with two consecutive blocks using the switcher prop to create the TS/JS toggle.
Added the highlight prop to each example to emphasize the relevant configuration option.
Updated surrounding prose (e.g., next.config.js -> next.config.mjs) to maintain consistency.
Fixes #84017
Allow CI Workflow Run
- [ ] approve CI run for commit: 1f13ef936f936340d9afc21f064b05143e926980
Note: this should only be enabled once the PR is ready to go and can only be enabled by a maintainer
Allow CI Workflow Run
- [ ] approve CI run for commit: 43312f00e800cb01c89870bd4b9062f0fea97eda
Note: this should only be enabled once the PR is ready to go and can only be enabled by a maintainer
Hello @icyJoseph , could you please take a look at my PR for this issue: https://github.com/vercel/next.js/issues/84017 ? Thanks!
Hello @icyJoseph , could you please take a look at my PR for this issue: #84017 ? Thanks!
Hi, no need to tag me again. I've been tagged in #84017 - As you may understand a +2,865 −354, will take a bit of time to go through, amongst other things going on. AI thinks things look alright though, but I wanna double check the diff.
I am already seeing some things to comment. We should take this opportunity to start referring to the next.config.js file, as Next.js config file - since today it can be mjs, js,ts, mts...
It'd be nice to introduce this consistency first into the text blocks, not the headings and links just yet.
In the files I've seen I find the use of highlight to perhaps not be necessary, since the snippet shows only one config, what are we highlighting against? And I see in some files the PR highlights the entire experimental block, in others it highlights a nested key only, this is inconsistent I feel like.
- docs/01-app/03-api-reference/05-config/01-next-config-js/authInterrupts.mdx highlights the
authInterruptsonly - docs/01-app/03-api-reference/05-config/01-next-config-js/browserDebugInfoInTerminal.mdx highlights the entire
experimentalkey
Again, what are these highlighting against? these are the only options listed in the config.
I am already seeing some things to comment. We should take this opportunity to start referring to the
next.config.jsfile, asNext.js config file- since today it can bemjs,js,ts,mts...It'd be nice to introduce this consistency first into the text blocks, not the headings and links just yet.
In the files I've seen I find the use of highlight to perhaps not be necessary, since the snippet shows only one config, what are we highlighting against? And I see in some files the PR highlights the entire experimental block, in others it highlights a nested key only, this is inconsistent I feel like.
- docs/01-app/03-api-reference/05-config/01-next-config-js/authInterrupts.mdx highlights the
authInterruptsonly- docs/01-app/03-api-reference/05-config/01-next-config-js/browserDebugInfoInTerminal.mdx highlights the entire
experimentalkeyAgain, what are these highlighting against? these are the only options listed in the config.
Thanks,
I'll update the text blocks to refer to the Next.js config file
I also agree that the highlighting is unnecessary and inconsistent. I'll remove the highlight prop from all the updated code snippets to make them cleaner.
Will push the changes shortly.
@icyJoseph , hello i haven't got any updates regarding this PR yet.
Hi, sorry this is taking a while to review. It is a lot of files and some with changes I'd like to make sure are correct.
Also there's a merge conflict, could we try to resolve that. Appreciate the effort! I have reviewed 45/57 files so far. We are nearly there.
Notifying the following users due to files changed in this PR based on this repo's notify modifiers:
@timneutkens, @ijjk, @shuding, @huozhi:
packages/next/src/server/config.ts
Hi, sorry this is taking a while to review. It is a lot of files and some with changes I'd like to make sure are correct.
Also there's a merge conflict, could we try to resolve that. Appreciate the effort! I have reviewed 45/57 files so far. We are nearly there.
I realize this PR has a lot of changes, especially after rebasing onto the latest canary branch. I appreciate your time reviewing it and am happy to help clarify or split anything if that makes it easier. Please feel free to point out wherever I might be wrong.Thanks
Hi @icyJoseph ,
I’ve just resolved the new merge conflicts and pushed the latest updates.
I understand this PR touches a lot of files, and really appreciate the time you’ve been spending reviewing it.
Since the branch has been getting frequent upstream changes, it’s becoming a bit challenging to keep resolving new conflicts.
If possible, it would be great if we could get this merged soon. Thanks again for your time and support!
I wonder how can we unblock this PR and merge, perhaps let's not modify the files were we show loading paths? those that use require() etc and are changed for import.meta APIs - we can iterate those separately
I wonder how can we unblock this PR and merge, perhaps let's not modify the files were we show loading paths? those that use require() etc and are changed for import.meta APIs - we can iterate those separately
Done.
@icyJoseph
Is there anything else needs to be done by me?
I haven't forgotten about this PR! Just reviewing and writing a few other things at the moment, as soon as I have some time slot I'll get back to it