Start of a recommended base #15
Conversation
There was a problem hiding this comment.
Minor suggestions on nice defaults to propagate here:
declaration: truehas the (possibly undocumented?) side-effect of catching more errors (increased strictness is good)noEmitOnError: truehelps prevent accidents (speaking from embarrassing bitter experience)target: "esnext"&module: "esnext"will help steer codebases towards less transpilation (good for everyone)useDefineForClassFields: trueensures checking & emit compatibility with engines
|
@robpalme Agreed! I think However, It only seems relevant when |
|
@styfle not quite.
|
Co-authored-by: Steven <steven@ceriously.com>
|
There's also microsoft/TypeScript#39354 |
|
We keep punting on this in design meetings, I'll get it seen soon enough I agree with all of the feedback, updated the PR. I'm not 100% enough on the target/module recommendation to put that in yet, will bring it up - I think I prefer it though, better to start at the top and let people choose to go back to earlier then the other way around. |
| "allowSyntheticDefaultImports": true, | ||
|
|
||
| /** Improves `tsc` launch speed in favour of some accuracy in your @types **/ | ||
| "skipLibCheck": true, |
There was a problem hiding this comment.
The docs for skipLibCheck seem to be different than what your comment says here.
The docs say that this property will "Skip type checking of all declaration files (*.d.ts)."
https://www.typescriptlang.org/docs/handbook/compiler-options.html
There was a problem hiding this comment.
Yeah I can confirm this option turns off type checking of hand-written DTS files in your project, unfortunately. As a result I find it difficult to recommend.
There was a problem hiding this comment.
Yeah, it's a good point - I was thinking of types at the same time. We opted to recommend it for speed and that most dts files come from @types where we have tonnes of testing infra (and that most folks won't go fix these things upstream) - we'd probably fix the issues, others would get stuck
There was a problem hiding this comment.
That sounds like the common case - where the declarations files are for dependencies as opposed to defining types for files inside your project.
I know this isn't the right place to suggest it, but maybe the implementation of skipLibCheck could be updated to make this distinction.
|
Managed to get this into a design review (we only do one a week, but given everyone is remote they're really filled, so might be switching to two a week) - general gist for this is that we think What that means for this PR is that I'm going to replace this with a Then people know there is only 1 recommended by TS tsconfig. This probably means dropping some of the existing flags which I think are recommended. I also wonder if something like |
|
Alright, I've got this in with #25 It's bit kludgy with me manually editing all the other json files but otherwise I'll need to create the JSON files by string concatenation and I've already punted on this since May |
Opening this PR ahead a the TS design meeting for feedback