changing tsconfig.json target from "es5" to "esnext"

[stefanprobst]

typescript beginner question: as far as i understand, nextjs uses tsc only for type checking and babel for compilation -- is it therefore safe to change the default tsconfig target: es5 to target: esnext for a small perf win?

[ChrisCrossCrash]

I'm also curious about this question.

Perhaps target defaults to es5 because that way, it can catch errors immediately in TypeScript that would otherwise surface as build errors when the code is compiled by Babel.

If anybody can provide more insight, please let us know.

Update: I think I figured it out

I think I understand why the default target is es5 now.

Sometimes you'll use some >ES5 syntax that Babel doesn't know what to do with because there's no ES5 equivalent polyfill. If you use target: "esnext" in your tsconfig.json you'll fix the TypeScript error, but since Next JS is targeting es5 when it builds, then the error that would have been caught by TypeScript will end up as a build error.

For example, here is the problem I was having:

import { Footer } from './Footer'
import { render } from '@testing-library/react'

let component: HTMLElement

beforeEach(() => {
  component = render(<Footer />).getByTestId('footer')
})

it("doesn't contain broken links", async () => {
  const links = component.querySelectorAll('a') as any
  // TS Error on `links` in for loop: TS2569: Type 'NodeListOf ' is not
  // an array type or a string type. Use compiler option
  // '--downlevelIteration' to allow iterating of iterators.
  for (const link of links) {
    const response = await global.fetch(link.href)
    expect(response.status).toBe(200)
  }
})

This code is just for running tests. The for (const link of links) {...} is not part of my application, so I was able to get away with casting it as any:

const links = component.querySelectorAll('a') as any

[victordidenko]

Top level await is not compatible with target: es5, but changing tsconfig.json didn't solve the problem for me :( Had to disable type checking at all:

typescript: {
  ignoreBuildErrors: true,
},

[ackvf]

Did your built app work?

[kachkaev]

Is it therefore safe to change the default tsconfig target: es5 to target: esnext for a small perf win?

It should be safe. The value of target does not affect the build output (I am using Next 12.1.0):

cd /tmp

yarn create next-app --typescript next-app-with-ts
cd next-app-with-ts

cat tsconfig.json
yarn build

npx replace es5 es2021 tsconfig.json
yarn build

As you can see from the screenshot, bundle sizes are identical. At the time of writing, Next always uses es5 + commonjs, regardless of what’s in tsconfig.json.

I guess the reason why Next defaults to es5 in tsconfig.json is to help folks run scripts that can be co-located with the Next app. If, say, target is es2021 and someone on Node 12 runs ts-node scripts/hello.ts, there may be syntax errors. E.g. hello?.length will not work.

[ackvf]

Is it possible to build to esnext at all? I am not using any obsolete apps on my own server.

[chrisweb]

Tim Neutkens from the next.js team confirmed that next.js does not use tsc, so target has no effect on the build: #37271 (comment)

actually target got even removed: 4e879ec, so this should be the case in every release > 13.1.2

[ecrofeg]

This is driving me nuts, why I can't control the way my app is built?

[PaulRBerg]

@ecrofeg because Next.js uses its own compiler. TypeScript is used only for type-checking.

[ackvf]

I wonder if we can use some Next tsconfig type to limit our choices. Is it possible to use DesiredCompilerOptionsShape? 4e879ec

[bdombro]

You can and should set target based on your node version assuming you aren't on bleeding node. Check this page for which recommended target: https://github.com/microsoft/TypeScript/wiki/Node-Target-Mapping

[stephenhmarsh]

thanks for this... so the basic premise is target the version of Node that you run Next.js on, not what you want the output/compatibility to be for users?

[bdombro]

Correct. Next code optimizations/compat stuff isn't done in Typescript, so this setting has no impact on what's output to the browser