Reuse tsconfig
Ref: https://github.com/tsconfig/bases/tree/main/template
This commit is contained in:
parent
fb1dccc7db
commit
199d322939
7 changed files with 21 additions and 155 deletions
|
@ -32,3 +32,8 @@ To see what packages depend on each other locally, use
|
|||
```sh
|
||||
yarn workspaces info
|
||||
```
|
||||
|
||||
## Tips
|
||||
|
||||
- Too see what tsc is seeing (say when it is trying to type-check `@/utils`),
|
||||
use `yarn workspace @/utils tsc --showConfig`.
|
||||
|
|
|
@ -1,5 +1,5 @@
|
|||
{
|
||||
/* TSConfig for TypeScript projects that get transpiled by Next.js */
|
||||
/* TSConfig for a TypeScript project that'll get transpiled by Next.js */
|
||||
|
||||
/* TSConfig docs: https://aka.ms/tsconfig.json */
|
||||
"compilerOptions": {
|
||||
|
@ -71,9 +71,5 @@
|
|||
/* e.g. makes array indexing returns undefined */
|
||||
"noUncheckedIndexedAccess": true,
|
||||
"exactOptionalPropertyTypes": true
|
||||
},
|
||||
/*
|
||||
* Typecheck all files (here or in subfolders) with the given extensions
|
||||
*/
|
||||
"include": ["**/*.ts", "**/*.tsx"]
|
||||
}
|
||||
}
|
||||
|
|
|
@ -19,6 +19,9 @@ const gitSHA = cp.execSync('git rev-parse --short HEAD', {
|
|||
});
|
||||
|
||||
/**
|
||||
* The base Next.js config. Before exporting this, we wrap this in
|
||||
* {@link withSentryConfig}.
|
||||
*
|
||||
* @type {import('next').NextConfig}
|
||||
*/
|
||||
const nextConfig = {
|
||||
|
|
|
@ -5,5 +5,8 @@
|
|||
"exports": {
|
||||
"./components/*": "./src/components/*.tsx",
|
||||
"./*": "./src/*.ts"
|
||||
},
|
||||
"devDependencies": {
|
||||
"@/build-config": "*"
|
||||
}
|
||||
}
|
||||
|
|
|
@ -1,77 +1,5 @@
|
|||
{
|
||||
/* Docs: https://aka.ms/tsconfig.json */
|
||||
"compilerOptions": {
|
||||
/* We use TypeScript (tsc) as a type checker, not as a build tool */
|
||||
"noEmit": true,
|
||||
|
||||
/*
|
||||
* Tell TypeScript which all things it can assume that our target
|
||||
* runtime will have.
|
||||
*
|
||||
* In our case, we tell it that the code will run in a modern browser,
|
||||
* and will have access to a latest JS (esnext) and the DOM (dom). Our
|
||||
* transpiler (Next.js) will ensure that these things hold.
|
||||
*
|
||||
* Unlike the other individual library components (say how "esnext"
|
||||
* implies "esnext.*"), "dom.iterable" (the ability to iterate over DOM
|
||||
* elements) is not a subset of "dom" and needs to be listed out
|
||||
* explicitly.
|
||||
*
|
||||
* Note that we don't need to specify the `target` compilerOption, since
|
||||
* tsc isn't actually generating (emitting) the JavaScript.
|
||||
*/
|
||||
"lib": ["esnext", "dom", "dom.iterable"],
|
||||
|
||||
/*
|
||||
* The module system to assume the generated JavaScript will use.
|
||||
*
|
||||
* Since we're using a bundler, we should set this to "esnext"
|
||||
* https://www.typescriptlang.org/docs/handbook/modules/guides/choosing-compiler-options.html
|
||||
*/
|
||||
"module": "esnext",
|
||||
|
||||
/*
|
||||
* Tell TypeScript how to lookup the file for a given import
|
||||
*
|
||||
* From the TypeScript docs:
|
||||
*
|
||||
* > 'bundler' is for use with bundlers. Like node16 and nodenext, this
|
||||
* mode supports package.json `imports` and `exports`, but unlinke the
|
||||
* Node.js resolution modes, bundler never requires file extensions on
|
||||
* relative paths in imports.
|
||||
*
|
||||
* > bundler does not support resolution of `require` calls.
|
||||
*/
|
||||
"moduleResolution": "bundler",
|
||||
|
||||
/* Allow use of `.tsx` files, but don't tranform them */
|
||||
"jsx": "preserve",
|
||||
|
||||
/* Ask TypeScript to warn us if we use TypeScript features that cannot
|
||||
be used by single-file transpilers */
|
||||
"isolatedModules": true,
|
||||
/* Enable various workarounds to play better with CJS libraries */
|
||||
"esModuleInterop": true,
|
||||
|
||||
/* Speed things up by not type checking `node_modules` */
|
||||
"skipLibCheck": true,
|
||||
/* Require the `type` modifier when importing types */
|
||||
"verbatimModuleSyntax": true,
|
||||
/* Enable importing .json files */
|
||||
"resolveJsonModule": true,
|
||||
|
||||
"strict": true,
|
||||
/* Stricter than strict */
|
||||
"noImplicitReturns": true,
|
||||
"noUnusedParameters": true,
|
||||
"noUnusedLocals": true,
|
||||
"noFallthroughCasesInSwitch": true,
|
||||
/* e.g. makes array indexing returns undefined */
|
||||
"noUncheckedIndexedAccess": true,
|
||||
"exactOptionalPropertyTypes": true
|
||||
},
|
||||
/*
|
||||
* Typecheck all files (here or in subfolders) with the given extensions
|
||||
*/
|
||||
"extends": "@/build-config/tsconfig.transpile.json",
|
||||
/* Typecheck all files with the given extensions (here or in subfolders) */
|
||||
"include": ["**/*.ts", "**/*.tsx"]
|
||||
}
|
||||
|
|
|
@ -4,5 +4,8 @@
|
|||
"private": true,
|
||||
"exports": {
|
||||
"./*": "./src/*.ts"
|
||||
},
|
||||
"devDependencies": {
|
||||
"@/build-config": "*"
|
||||
}
|
||||
}
|
||||
|
|
|
@ -1,77 +1,5 @@
|
|||
{
|
||||
/* Docs: https://aka.ms/tsconfig.json */
|
||||
"compilerOptions": {
|
||||
/* We use TypeScript (tsc) as a type checker, not as a build tool */
|
||||
"noEmit": true,
|
||||
|
||||
/*
|
||||
* Tell TypeScript which all things it can assume that our target
|
||||
* runtime will have.
|
||||
*
|
||||
* In our case, we tell it that the code will run in a modern browser,
|
||||
* and will have access to a latest JS (esnext) and the DOM (dom). Our
|
||||
* transpiler (Next.js) will ensure that these things hold.
|
||||
*
|
||||
* Unlike the other individual library components (say how "esnext"
|
||||
* implies "esnext.*"), "dom.iterable" (the ability to iterate over DOM
|
||||
* elements) is not a subset of "dom" and needs to be listed out
|
||||
* explicitly.
|
||||
*
|
||||
* Note that we don't need to specify the `target` compilerOption, since
|
||||
* tsc isn't actually generating (emitting) the JavaScript.
|
||||
*/
|
||||
"lib": ["esnext", "dom", "dom.iterable"],
|
||||
|
||||
/*
|
||||
* The module system to assume the generated JavaScript will use.
|
||||
*
|
||||
* Since we're using a bundler, we should set this to "esnext"
|
||||
* https://www.typescriptlang.org/docs/handbook/modules/guides/choosing-compiler-options.html
|
||||
*/
|
||||
"module": "esnext",
|
||||
|
||||
/*
|
||||
* Tell TypeScript how to lookup the file for a given import
|
||||
*
|
||||
* From the TypeScript docs:
|
||||
*
|
||||
* > 'bundler' is for use with bundlers. Like node16 and nodenext, this
|
||||
* mode supports package.json `imports` and `exports`, but unlinke the
|
||||
* Node.js resolution modes, bundler never requires file extensions on
|
||||
* relative paths in imports.
|
||||
*
|
||||
* > bundler does not support resolution of `require` calls.
|
||||
*/
|
||||
"moduleResolution": "bundler",
|
||||
|
||||
/* Allow use of `.tsx` files, but don't tranform them */
|
||||
"jsx": "preserve",
|
||||
|
||||
/* Ask TypeScript to warn us if we use TypeScript features that cannot
|
||||
be used by single-file transpilers */
|
||||
"isolatedModules": true,
|
||||
/* Enable various workarounds to play better with CJS libraries */
|
||||
"esModuleInterop": true,
|
||||
|
||||
/* Speed things up by not type checking `node_modules` */
|
||||
"skipLibCheck": true,
|
||||
/* Require the `type` modifier when importing types */
|
||||
"verbatimModuleSyntax": true,
|
||||
/* Enable importing .json files */
|
||||
"resolveJsonModule": true,
|
||||
|
||||
"strict": true,
|
||||
/* Stricter than strict */
|
||||
"noImplicitReturns": true,
|
||||
"noUnusedParameters": true,
|
||||
"noUnusedLocals": true,
|
||||
"noFallthroughCasesInSwitch": true,
|
||||
/* e.g. makes array indexing returns undefined */
|
||||
"noUncheckedIndexedAccess": true,
|
||||
"exactOptionalPropertyTypes": true
|
||||
},
|
||||
/*
|
||||
* Typecheck all files (here or in subfolders) with the given extensions
|
||||
*/
|
||||
"include": ["**/*.ts", "**/*.tsx"]
|
||||
"extends": "@/build-config/tsconfig.transpile.json",
|
||||
/* Typecheck all files with the given extensions (here or in subfolders) */
|
||||
"include": ["**/*.ts"]
|
||||
}
|
||||
|
|
Loading…
Add table
Reference in a new issue