next.config.ts

[virzak]

Feature request

Is it possible to use next.config.ts instead of next.config.js?
Currently none of the typescript examples use typescript in the config file. Is it even possible?

@resir014

[timneutkens]

If you want to do something like this it's your own responsibility to compile next.config.ts to next.config.js. We're not planning to transpile next.config.js.

[resir014]

@virzak Yeah, not without much effort. It will require runtime transpilation w/ ts-node, and it adds unnecessary complexity to Next.js.

You can however, use // @ts-check to type check your next.config.js just like you would in Flowtype.

[ManAnRuck]

any changes here since nextJs Core is running with typescript?

[kachkaev]

Any chance this issue could be reconsidered? It was closed over a year ago and a lot has changed since then, TS support is now part of the core.

A specific reason I would like to have next.config.ts is because I want to set publicRuntimeConfig: { appInfo: generateAppInfo() }. The generateAppInfo() function sits in helpers.ts and returns a data structure that is type-checked against the AppInfo interface. The contents include enabled feature switches, git commit hash, sentry id and other things a launched app instance would need.

The same generateAppInfo() function is used in Jest mocks, so moving its implementation out of a ts file right into next.config.js would not be possible. Seems like I now need to extract generateAppInfo() into a separate js file, thus losing type checking against AppInfo interface 🤔

[timneutkens]

Still the same as #5318 (comment)

Compiling it would slow down bootup and make config loading significantly more complex compared to the benefits.

[DCzajkowski]

I don't think this would be an issue, since Vite (which aims to be the fastest at spinning up a dev server) uses vite.config.ts by default. In my experience, esbuild with TS files (which transpiles without type-checking) is as fast as with JS files.

I would reconsider this option in 2022, as TS is much more widely adopted now.

[kachkaev]

I believe the main performance problem is production-related. What if next.config.ts was compiled into .next directory along with other code, which would remove a need to pass it via babel or ts-node in production? Boot time should remain the same if not slightly better given that there will be scope for build-time optimisations.

[timneutkens]

It's both development and production. Note that this file is a config file and generally shouldn't have anything complex in there.

[jwarkentin]

It should just build and cache the config like everything else so it doesn't slow bootup performance. Plus, I would be shocked if it was a significant performance impact on bootup compared to the benefits. It's frustrating not being able to use a consistent language throughout my entire project and include the same linting tools or esnext syntax.

Note that this file is a config file and generally shouldn't have anything complex in there.

Umm, maybe for super simple use cases? I don't know. I work on big complex apps that require a lot of customization and tweaking. Data on this would be interesting. They certainly felt it was worthwhile to transpile preact.config.js and I haven't seen any noticeable performance issues with that. Not sure why this would be any different.

One particularly useful tool for modifying configs imperatively like this that loses a lot of benefits without transpiling TS is Ramda. That's my FP toolbelt for everything because it has awesome TS support for dynamic type inference when currying.

[reaktivo]

Is supporting a transpiled next.config.ts still not being considered? Our specific use case is simply that we have multiple functions a services directory that are fully typed. The services consume our APIs and are fully typed. Currently we have to duplicate the service, one typed and one untyped, since we also need them to consume our APIs and generate our exportPathMap.

[timneutkens]

Generating a list of urls to export will be covered by getStaticPaths in #9524

[lsm]

You probably already have the following 2 packages installed if you are using typescript with nextjs:
@babel/core
@babel/preset-typescript

Then you can use a function like the one below to require typescript file on the fly:

function requireTypescript(path) {
  const fileContent = require('fs').readFileSync(path, 'utf8')
  const compiled = require('@babel/core').transform(
    fileContent,
    {
      filename: path,
      presets: [ '@babel/preset-typescript' ],
    },
  )
  return eval(compiled.code)
}

Then use it in your next.config.js like this:

const myModule = requireTypescript('./path/to/mymodule.ts')

Note: you will need to inject some path information if your ts file is not in the same folder of next.config.js and you have relative import inside the ts file you are requiring. So, keep the target ts file simple.

[OnurGvnc]

simpler solution with built-in swc in next package

require.extensions['.ts'] = function (mod, filename) {
  const content = require('fs').readFileSync(filename, 'utf8')
  const output = require('next/dist/build/swc').transformSync(content, {
    module: {
      type: 'commonjs',
    },
  })
  mod._compile(output.code, filename)
}

module.exports = require('./next.config.ts')

[obadajasm]

One thing I think it might be helpful to add, in my .ts file I had a default export so I had to add '@babel/plugin-transform-modules-commonjs' plugin, so I end up with this:

function requireTypescript(path) {
  const fileContent = require('fs').readFileSync(path, 'utf8')
  const compiled = require('@babel/core').transform(
    fileContent,
    {
      filename: path,
      presets: [ '@babel/preset-typescript' ],
      plugins: [ 
        '@babel/plugin-transform-modules-commonjs',
    ],

    },
  )

  return eval(compiled.code)
}

[timneutkens]

Note about #5318 (comment)

• Slows down bootup when using next start
• Slows down bootup in development

[Janpot]

But if you decided to use typescript in your project, didn't you already trade in some performance for type safety? How come the performance impact is not seen as problematic when it happens on every change of a file, but is suddenly so insurmountable when it's once on boot? And If you cache it a bit smart it's not even happening on every boot.

If the concern is that people would blame next.js for slow bootup instead of typescript, maybe a log could be added like

> compiled next.config.ts (1700ms)

That would make clear to people which impact the use of which tool has for them.

[timneutkens]

@Janpot because it's cached inside Next.js and not with this method. On top of that it affects production boot if you use next start, as it loads next.config.js. Next.js doesn't compile typescript on production boot.

[Janpot]

Yes, I agree, not with this method. But if next were to hypothetically implement this feature, I presume it wouldn't be too hard to add cache. Since next.js already has infrastructure to compile and cache typescript. And for production boot it could precompile when running next build? All of that would make the performance impact very minimal.

[stefee]

Can I suggest someone create a Discussions thread for this? There’s a fair amount of chatter here but the use case has been made quite clear already, so I’d prefer if this thread is kept to just updates regarding the implementation.

[stefee]

@balazsorban44 @timneutkens Can someone on the Vercel team create a tracking issue for this please? I'd still like to follow updates on the implementation, but I'm just not interested in hearing about temporary work-arounds (hence my suggestion to create a separate discussion).

[balazsorban44]

Feature requests are usually converted to a discussion, this one was a bit older and thus kept around as an issue. If any new details come out, we will likely post about them here or on relevant communication channels. 👍

[stefee]

Okeydoke

[KATT]

Here's a solution that works with type-safety, autocompletion, and possible to infer publicRuntimeConfig

Code

// @ts-check
/* eslint-disable @typescript-eslint/no-var-requires */
const { env } = require('./src/server/env'); // Optional - parses env vars with a zod-schema on build/start

/**
 * Don't be scared of the generics here.
 * All they do is to give us autocompletion when using this.
 *
 * @template {import('next').NextConfig} T
 * @param {T} config - A generic parameter that flows through to the return type
 * @constraint {{import('next').NextConfig}}
 */
function getConfig(config) {
  return config;
}

/**
 * @link https://nextjs.org/docs/api-reference/next.config.js/introduction
 */
module.exports = getConfig({
  /**
   * Dynamic configuration available for the browser and server.
   * Note: requires `ssr: true` or a `getInitialProps` in `_app.tsx`
   * @link https://nextjs.org/docs/api-reference/next.config.js/runtime-configuration
   */
  publicRuntimeConfig: {
    NODE_ENV: env.NODE_ENV,
  },
});

Repo

• https://github.com/trpc/examples-next-prisma-starter/blob/main/next.config.js
• https://github.com/trpc/examples-next-prisma-starter/blob/main/src/utils/publicRuntimeConfig.ts

[M3kH]

I will add my use-case which I think is relevant to the discussion.
We would like to use NextJS for our multi-tenant solution, the application is the same but the configuration of each tenant is different.

Some of the key aspects of the multi-tenancy are:

• Capable of have different basePath
• Capable of serving from a different host
• Capable of have different assetPrefix
• Different runtimeConfiguration
• Configuration aware _middleware

Where many of these can be solve trough the .env I don't believe is the best solution for our uses cases, renounce in type checking and utilities that we could build for create such complex configuration is a big loss for us.

I think for us the tradeoff of having a slower boot time vs high type-safe configurability, is something we're would be willing to sacrifice.
Be aware that this is not just types, we build those configurations with helpers that we would like to have in TypeScript because we don't want to write JavaScript files with separate Type definition on each case where we need the same config in a runtime (eg: _middleware.ts and next.config.js).

Hope this help in understanding why we think is important adopt TypeScript for the NextJS configuration.

[dopry]

Just to add on to use cases. I'm querying redirects from our API. We already have a context setup for our API the sets up the client. It's all written in typescript. I'd like to be able to import it into our config without duplicating the client setup code.

[ristomatti]

I'm not sure if you're looking for workarounds but you can define most of the types outside next.config.js and just reference them. See my comment a bit above for an example: #35969 (reply in thread).

[deiga]

@ristomatti I think OP is looking for a solution to import TS code into next.config (as am I), types don't solve this.

[ristomatti]

@deiga Oops, read it too fast! This workaround could still work by writing type interfaces for the common code, then write the implementation to a a type annotated JS file. With strict enough types, you'll get almost the same DX.

Or alternatively extract the common code into it's own module/library) or by simply adding a transpilation step for these parts?

[rtritto]

Any update?

In my use case, I need to import a ts file in next.config.js.
As workaround, I'm using ts-import.

[dapabe]

It works like a charm.
In next.config.mjs file

  import * as tsImport from "ts-import";
  const loadTS = (filePath) => tsImport.loadSync(filePath);
  
  const LangsSupported = loadTS("./src/utils/constants.ts").LangsSupported;
  
/**
 *  @type {import('next').NextConfig}
 */
  export default {
    experimental: {
      appDir: true
    },
    i18n: {
      locales: LangsSupported,
      defaultLocale: LangsSupported[0],
  },
};

[thany]

Getting an ERR_REQUIRE_ESM on this one, at the line where it's calling loadSync. Looks like ts-import doesn't actually import anything, but utilises require().

Yes indeed, I do have "type": "module" in my package.json
No indeed, I will not be removing it 🙂

[rtritto]

@thany I already opened the issue radarsu/ts-import#29

[SalahAdDin]

Not next.config.ts yet?

[jrabek]

Another option/workaround to consider for loading a ts file from your next.config.js:

function requireTypescript(path) {
  const fileContent = require('fs').readFileSync(path, 'utf8');
  const compiled = require('@babel/core').transform(fileContent, {
    filename: path,
    presets: ['@babel/preset-env', '@babel/preset-typescript'],
  });
  const Module = module.constructor;
  const m = new Module();
  m._compile(compiled.code, path);
  return m.exports;
}

Then

const { configObject, anotherConfigObject } = requireTypescript('someConfigFile.ts');

[rtritto]

This change should help/fix (it's released in Node v19.6.0 and there is a backport to v18).

[EmJee1]

TailwindCSS added support for this in the 3.3 release https://tailwindcss.com/blog/tailwindcss-v3-3#esm-and-typescript-support. Would be great to be able to write Next config files in TypeScript

[Jamiewarb]

Nuxt also has support for this

[CMCDragonkai]

Just wanted to note it appears to work for me using .mts. But that's also because I've got ESM all activated too.

[SalahAdDin]

Can you explain to us how you use it? Thanks.

[mburumaxwell]

It complies when using .mts but does it work with the options specified? For example, does setting output: 'standalone' work?

[Mon-ius]

Any update about using next.config.ts on the typescript based project?

[SalahAdDin]

Nothing yet?

[devjiwonchoi]

Opened PR #57656, feel free to give feedback!

[devjiwonchoi]

https://github.com/devjiwonchoi/next-config-ts-preview

This is an early access I've worked on, the PR #57656 is still pending to be reviewed by the team.
Please try out the preview above and send feedback so I can add more test cases and fix them!

If any issues, please file them here.

To integrate into your working project, run the following commands:

pnpm add -D next-config-ts-preview
pnpm next-config-ts-preview

NOTE: The following scripts are modifying the next package in your node_modules. To undo them, reinstall the dependencies.

[yunsii]

Awesome job, I will try it later.

[devjiwonchoi]

cc @virzak

This feature was shipped on v15.0.0-canary.60, please give it a try and feel free to ping me if any issues found!

npm i next@canary

[stefanprobst]

@devjiwonchoi thanks 🎉!! one question: does next.config.ts allow importing "server-only" modules (see #65652)?

[GoodbyeNJN]

@devjiwonchoi thanks for your work!

I have a problem, currently I cannot use ESM related features (such as import.meta, etc.) in next.config.ts.

Since the Nodejs ecosystem has begun to migrate to ESM, can we consider supporting next.config.ts in ESM type?

[GoodbyeNJN]

After looking deeply into the source code, I found that the actual process is: 1. Use swc to transform into a string, 2. Create a dummy module from this string and require it.

I think this process needs to be refactored. I suggest using swc to bundle the configuration file and dependencies into one, writing it to cwd, and then using native import/require, and delete the file after imported. If any fatal errors occur during this process, the file will remain in the directory and users can use it to troubleshoot the problem.

I would also recommend additional support for next.config.mts, for which the .mjs extension is forced to be used when writing files, while next.config.ts keeps using .js extension when writing.

[devjiwonchoi]

@stefanprobst No I don't think it fixes your issue directly.

@GoodbyeNJN Wow, thank you for your great advice!
To be honest, the future refactor will be mostly identical to your idea.
We will definitely support ESM seamlessly before marking it as stable, thank you.

[GoodbyeNJN]

@devjiwonchoi Very happy to hear this news and look forward to having this exciting feature available soon. Thanks again for your work on this.