In the 8.1.1 canaries with native TypeScript support, Next is assuming that tsconfig.json will be in the source directory, rather than above it.
When it doesn’t find it, it creates a blank tsconfig.json file that then doesn't have the right configuration.
I discovered this when migrating from a working withTypescript installation of Next 8.0.
Using the following directory structure:
- tsconfig.json
- next.config.js
- src/
- components/
- pages/
- build/
Where tsconfig.json has:
{
"extends": "…",
"compilerOptions": {
"rootDir": "src",
"outDir": "build",
"sourceMap": true,
"declaration": false
},
"include": [
"src/**/*"
]
}
And next.config.js:
module.exports = {
distDir: path.join('..', 'build', '.next'),
assetPrefix: process.env.ASSET_PREFIX || '/',
publicRuntimeConfig: {
},
}
Run:
$ npx next build src
Next should find that there’s a tsconfig.json file in the level above src and use that, in the same way that it finds the next.config.js file.
My existing setup worked fine with withTypescript.
Next.js requires the tsconfig.json be configured in some very specific ways so it's probably not best if we use the parent directory one.
If you add the extends key to the created tsconfig.json does this achieve the desired behavior?
Is there a way to disable Next.js’s TypeScript support? TBH I was pretty happy running things through Babel’s TypeScript handling. It made everything very consistent in development (considering how other compiling tools have good Babel support, like Jest and Storybook).
I'm nervous about how Next.js’s modifying of tsconfig.json and demands about where it is placed will affect the non-Next.js TypeScript code in my project.
Are you using typescript for any compilation or just typechecking? If it’s not used for compilation (and you’re just stripping the types with @babel/preset-typescript) then I think that next’s forking of a tsc process to do type checking should be optional. Or, let us configure a tsconfig.json location that Next doesn’t try to modify, and it’s up to us to make sure it has everything necessary to interpret Next-using apps.
I like that TS is going to be inbuild by default but agree with @fionawhim that the config property for tsconfig location should be provided. The BTW complaint is that config object API is not thoroughly described in Docs. Would be nice to have a full description of all properties like for example in Jest configuration Docs.
TypeScript and its config is only used for type-checking -- the options we configure are mandatory to match how a Next.js application is compiled.
This issue is going to be closed for now -- we avoid adding configuration unless it's absolutely necessary.
Like mentioned previously, you can achieve this behavior by extending the tsconfig.json in a parent directory.
We're not exploring an option to disable the TypeScript integration at this time.
Most helpful comment
Is there a way to disable Next.js’s TypeScript support? TBH I was pretty happy running things through Babel’s TypeScript handling. It made everything very consistent in development (considering how other compiling tools have good Babel support, like Jest and Storybook).
I'm nervous about how Next.js’s modifying of tsconfig.json and demands about where it is placed will affect the non-Next.js TypeScript code in my project.