Chapter 14 #14
Chapter 14 #14
Conversation
|
|
||
| ## Recommended Configuration | ||
|
|
||
| To start, here's a recommended base `tsconfig.json` configuration with options appropriate for most applications you're building: |
There was a problem hiding this comment.
Soon u might want to include noUncheckedSideEffectImports here too :p microsoft/TypeScript#58941
| "compilerOptions": { | ||
| /* Base Options: */ | ||
| "skipLibCheck": true, | ||
| "target": "es2022", |
There was a problem hiding this comment.
It's 2024 year already - any reason why you recommend 2022 here instead of 2023?
|
|
||
| ### `target` | ||
|
|
||
| The `target` option specifies the ECMAScript version that TypeScript should target when generating JavaScript code. |
There was a problem hiding this comment.
It also makes some features available, such as class private properties:
// @target: es5
class A {
#foo = 42 // error, u need a higher target
}
|
|
||
| ### `isolatedModules` | ||
|
|
||
| `isolatedModules` prevents some TypeScript language features that single-file transpilers can't handle. |
There was a problem hiding this comment.
More importantly, it's a mode that bans ambiguous situations like:
export { Foo } from './foo'
export const bar = 42;What should be emitted here as JS? Should it be:
export { Foo } from './foo.js'
export const bar = 42or something closer to this?
import './foo.js'
export const bar = 42The problem is that based on this single file we can't possibly know if Foo is a value or a type and if it can be referenced in the emitted JS.
|
|
||
| I tend to configure my `tsconfig.json` no stricter than `strict` and `noUncheckedIndexedAccess`. If you want to go further, there are several other strictness options you can enable: | ||
|
|
||
| - `allowUnreachableCode`: Errors when unreachable code is detected, like code after a `return` statement. |
There was a problem hiding this comment.
this is already the default... so if anything could disable it and not enable it as an extra strict option
|
|
||
| In this case, `createAlbum` will be imported as a runtime import, and `Album` will be imported as a type import. | ||
|
|
||
| In both cases, it's clear what will be removed from the emitted JavaScript. The first line will remove the entire import, and the second line will remove only the type import. |
There was a problem hiding this comment.
And thus the second option will still include the potential side-effects of the ./album.
| | -------------- | ---------------------- | ----------------------------------- | | ||
| | `album.mts` | `album.mjs` | ESM | | ||
| | `album.cts` | `album.cjs` | CJS | | ||
| | `album.ts` | `album.js` | Depends on `type` in `package.json` | |
There was a problem hiding this comment.
I think it's worth emphasizing this again here:
| | `album.ts` | `album.js` | Depends on `type` in `package.json` | | |
| | `album.ts` | `album.js` | Depends on `type` in the closest `package.json` | |
Nowadays it's not entirely uncommon to see such package.json files sprinkled in codebases here and there:
{ "type": "commonjs" }They look... weird but they are totally legal. You can use such package.json files to "switch" the default type of .js/.ts for a certain directory.
|
|
||
| - `preserve`: Keeps JSX syntax as-is. | ||
| - `react`: Transforms JSX into `React.createElement` calls. Useful for React 16 and earlier. | ||
| - `react-jsx`: Transforms JSX into `_jsx` calls, and automatically imports from `react/jsx-runtime`. Useful for React 17 and later. |
There was a problem hiding this comment.
which can be paired with jsxImportSource if one is using JSX with some other libraries like SolidJS
| } | ||
| ``` | ||
|
|
||
| But `server/tsconfig.json` can contain settings specific to the server-side application, such as removing the `dom` types: |
There was a problem hiding this comment.
this is also a good way of structuring things for src and test dirs... although usually people choose the easier option to just shove everything into a single tsconfig
| } | ||
| ``` | ||
|
|
||
| This approach is particularly useful for monorepos, where many different `tsconfig.json` files might need to reference the same base configuration. |
There was a problem hiding this comment.
where the new ${configDir} comes pretty handy for rootDir/outDir and similar
|
|
||
| - Project references allow you to run several `tsconfig.json` files in a single `tsc` command. | ||
| - Each sub-configuration should have `composite: true` in its `tsconfig.json` file. | ||
| - The root `tsconfig.json` file should have a `references` array that points to each sub-configuration, and `files: []` to prevent it from checking any files itself. |
There was a problem hiding this comment.
and each project depending on other projects within the monorepo should reference those too to ensure that everything can be built in the correct order
There was a problem hiding this comment.
It would be nice to mention here how people can utilize package.json#imports as a better - spec-driven - paths :)
No description provided.