Clément Valot

I'm currently giving it a try, and upgrading @sindresorhus/tsconfig to 3.0.1 breaks a lot of type-checking, notably with default imports, e.g `import is from '@sindresorhus/is';` raises `TS2339: Property 'object' does...

So after upgrading `@sindresorhus/tsconfig` to 3.0.1, which gives `moduleResolution=Node16`, type checking breaks, notably on `CacheableLookup`, `form-data-encoder` and `then-busboy` `tsc --traceResolution` gives an explanation: > ======== Resolving module 'form-data-encoder' from 'D:/WebstormProjects/@ClementValot/got/source/core/options.ts'....

Same issue with the minimal configuration above. Works with `moduleResolution=Node` but fails with `moduleResolution=NodeNext` or `Node16`

> If you use yarn you can workaround this issue by using yarn resolutions in your `package.json`. > > `swagger-typescript-api@^10.0.1` has a dependency of `typescript@^4.7.4` which resolves to `[email protected]` for...

Very naive question: Is there a reason not to implement a similar keyword for public readonly properties which would do the same, but without a setter? EDIT: I guess the...

How do we get a "maintainer to explicitly vouch for it"? Do we have to wave arms in the comments until it draws attention? :')

Sadly this is breaking for any team that uses both Windows and Unix/MacOS, the only workaround I've found is having `checkSumBehavior: ignore` in yarnrc and that's too big a trade-off...

I don't know nearly enough about this to understand why, are there features that are enabled with `2018` and wouldn't be with `latest`?