search

preactjs / wmr

👩‍🚀 The tiny all-in-one development tool for modern web apps.
https://wmr.dev/
MIT License
4.92k stars 109 forks source link

fix: typecheck in preact jsx.d.ts due to type change related to signals #955

Open robertmaier opened 1 year ago

robertmaier commented 1 year ago

as reported in https://github.com/preactjs/preact/issues/3934 the default property in RoutableProps breaks typechecks in Preact's jsx.d.ts file. This is caused by the addition of Signals to Preact, after which the property is defined as boolean | undefined | SignalLike<boolean | undefined> instead of a plain optional boolean.

The type ends up in preact's types because of namespace declaration merging.

@marvinhagemeister suggested to remove the default definition in preact-router here. Which is why I would suggest to also do this in preact-iso

An alternative solution would be to remove the type merging overall, but I don't have too much knowledge where the type is used.

changeset-bot[bot] commented 1 year ago

🦋 Changeset detected

Latest commit: 611650415693772e9d7d77f1dd1e7bce8ffa244d

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package | Name | Type | | ---------- | ----- | | preact-iso | Patch |

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

rschristian commented 1 year ago

Thanks for the PR!

Did you check that the types work correct? I don't think they would, as IntriniscAttributes needs to have RouteableProps else something like this wouldn't work: <Home default />. I think we need to exclude the HTMLAttributes's default from IntrinsicAttributes instead

robertmaier commented 1 year ago

@rschristian Thanks for haveing a first look. So you'd propose to do something like

type IntrinsicAttributes = Omit<preact.JSX.IntrinsicAttributes, 'default'>

if I understand correctly? I'll have a look if it solves our typecheck issue and let you know how it went.

rschristian commented 1 year ago

I think so? I'm admittedly not a huge fan of TS, but I think that's what we'd need to do, or something along those lines anyways.

It's weird (to me, anyways) that this is an issue though, as default shouldn't exist on components to cause conflicts. <Foo default /> shouldn't work (without these routers' types), so I'm not really sure I understand what the conflict is, if that makes sense.