Add defineConfig function to next/config

[AntoineKM]

What did I change?

I added a defineConfig function in runtime-config.external.ts.
But to be honest I think it would make more sense if it was in config-shared.ts the problem is that you would use

// next.config.ts
import { defineConfig } from “next/server"

instead of

// next.config.ts
import { defineConfig } from “next/config”

like vuejs, vitejs, solidjs, cypress or others do.

• e2e tests added (https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs)
• Documentation added
• Errors have a helpful link attached, see https://github.com/vercel/next.js/blob/canary/contributing.md

Why did I change it?

Fixes: https://x.com/nurodev/status/1813945402049388893

Preview and Usage

define-config.mp4

[ijjk]

Allow CI Workflow Run

• approve CI run for commit: 696ab0b

Note: this should only be enabled once the PR is ready to go and can only be enabled by a maintainer

[AntoineKM]

I did a review everything looks ok, let me know if you see anything you don't like, I'll correct it.

[leerob]

I have some reservations for adding a new API to the overall surface area now that next.config.ts exists. I could probably be convinced, but at least for this PR, we definitely shouldn't update every place in the docs to use the new API until it's a bit more tested (regardless).

[AntoineKM]

Hi @leerob, thanks for the feedback, so maybe the ideal would be to keep the current documentation and add a part in the documentation that explains how to use it and specifies that it's experimental?

[AntoineKM]

And also, do we keep it in the templates or add it when it's really been tested and approved?

[AntoineKM]

I've removed all the changes I've made to the documentation, because with hindsight, it will be preferable to integrate it gradually, depending on whether or not the community adopts this feature.
So I've only added to the documentation how it's used, I've also specified that it's experimental.

[imranbarbhuiya]

Even tho it's used in all the popular frameworks but what's the usecase of it when u can import the type and use it? Using a fn adds some runtime processing too and using ts type, you are still getting all the autocompletes

[AntoineKM]

Even tho it's used in all the popular frameworks but what's the usecase of it when u can import the type and use it? Using a fn adds some runtime processing too and using ts type, you are still getting all the autocompletes

Hey @imranbarbhuiya, I would say:

• Consistency across the ecosystem: Adopting this model in Next.js helps maintain consistency between frameworks.
• Code cleanliness: There's no need to explicitly annotate types everywhere (especially since new developers will probably have trouble understanding what they are), reducing boilerplate and making the configuration file easier to read/maintain.

Important

Keep in mind that this isn't the game changer, it should be seen as a help for newcomers and/or a way of aligning with competing frameworks and their users migrating to/learning Next.js.