Forcing `preact/compat` typings for typescript

[oltdaniel]

Describe the feature you'd love to see

Many use preact in combination with an existing UI framework that is build on the full react package. Thereby, there are a lot of issues with the typings in typescript and you've already have some documentation on it. But there is still a lot of improvement.

Proposal

1. Always recommend package.json aliases

As already mentioned in the documentation here we can alias react packages to preact compat. Lets extend that for the typings as well and fix the version stuff.

• First we also alias @types/react and @types/react-dom to the preact compat, to avoid loading any react related code that may break under the typescript checking.
• Additionally we add @* to the end of the alias, this fixes issues when e.g. you use npm ls @types/react.

{
 ...
 "dependencies": {
   "@types/react": "npm:@preact/compat@*",
   "@types/react-dom": "npm:@preact/compat@*",
   "react": "npm:@preact/compat@*",
   "react-dom": "npm:@preact/compat@*",
   "preact": "^10.10.0",
   ...
 }
}

2. Now we can also make our .tsconfig.json nicer

Due to the correct type resolution now thanks t the @types alias, we can now ignore the skipLibCheck and only add a types reference to preact compat to make sure nothing breaks.

Info This is related to a babel and webpack setup.

{
  ...
  "compilerOptions": {
    // Preact
    "jsx": "preserve",
    "jsxFactory": "h",
    "jsxFragmentFactory": "Fragment",
    "types": ["../preact/compat"]
  }
}

Info Everything related to babel/webpack and other packaging/compiling stuff is still relevant.

Testing

This is the configuration setup changes I made to make my project with Typescript and MaterialUI work without any type conflicts. Maybe you can reproduce this kind of setup and verify if it works as well. If so, I'm happy to make a pull request and extend the documentation.

Thanks for preact and all the work.

[rschristian]

Due to the correct type resolution now thanks t the @types alias, we can now ignore the skipLibCheck

Hm, I don't think this is the case. Mileage may vary with specific libs used, but there are some React types that Preact doesn't support. Any consumers of these will be met with errors if skipLibCheck isn't enabled.

The amount of config to appease TS these days is getting a tad ridiculous.

[oltdaniel]

Hm, I don't think this is the case. Mileage may vary with specific libs used, but there are some React types that Preact doesn't support. Any consumers of these will be met with errors if skipLibCheck isn't enabled.

Makes sense. That'S why I asked for testing, as I only work with MaterialUI. Might be interesting to see the general result.

[rschristian]

And that's a great idea actually, having a bunch of Preact projects set up with various React tools as a means of testing, even if it's just quick eye-balling for TS errors and the like. I don't think anything like that exists at the moment, but certainly is compelling.

And, as an addendum to your proposal, we maybe should swap out the skipLibCheck suggestion instead for excluding node_modules. Someone on the slack suggested this recently as skipLibCheck ignores .d.ts files in one's own project too, which can be troublesome. Will try to find who wrote that.

[rschristian]

Going to close this out, the Node aliases aren't guaranteed to help due to relying upon module resolution which can differ based on install order.

Type aliases are much more robust and less likely to be an issue.