-
Notifications
You must be signed in to change notification settings - Fork 5
Description
There's two ways we generate .d.ts files today:
@microsoft/api-extractorrolldown-plugin-dts
Which is controlled by setting dts in package.config.ts (api-extractor is the default):
import {defineConfig} from '@sanity/pkg-utils'
export default defineConfig({
dts: 'api-extractor' | 'rolldown'
})API extractor is a mature project (we're using v7.52.8!), but it has problems with newer TypeScript features that have slipped into multiple of our packages, best explained by this open issue: microsoft/rushstack#5106
When this issue happens it leads to incomplete typings in our .d.ts generated files, and none of our tooling is able to pick it up.
The only way I've found so far is to run TSC itself with the skipLibCheck set to false. Unfortunately this flag usually reports a lot of third party issues in node_modules that are not actionable, and there is no easy way of having it only run on the generated files in ./dist without also running it on everything that is referenced from node_modules, and then typechecking every single .d.ts file it encounters.
The way that sanity does it today is by running a sophisticated test suite that uses the TypeScript node api to manually filter out known errors, and catch new errors.
However that kind of setup is difficult to setup and maintain, it would be nice if @sanity/pkg-utils could do this for us when it runs --check.
I've already checked publint and @are-the-types-wrong/cli and they don't have this feature. It seems like we're gonna have to be the first.
It also seems like in the cases where api-extractor struggles, shifting to rolldown for dts gen resolves the issue. As rolldown is in beta it's still useful to type check generated dts to ensure that switching to it isn't causing a regression in typings.