React-day-picker: TypeScript types are incomplete and should maybe be moved to DefinitelyTyped

Created on 20 Dec 2018  Â·  7Comments  Â·  Source: gpbl/react-day-picker

TypeScript types are pretty incomplete, e.g. DayPickerInput is missing a large handful of parameters. This makes TypeScript obviously fail to compile since it's literally missing parameters.

There's no reason that the types should be in this repo (as far as I know), generally typescript types (especially for modules that are not natively TS) are supposed to be in @types/DefinitelyTyped so that we can choose to install them. Right now I cannot build my project using react-day-picker which is problematic.

You could probably argue 'just add a PR to add the missing props' but it still doesn't make sense to force the types on people, especially because it wasn't maintained at least once which leads me to assume it may get that way again.

Most helpful comment

Type definitions were on DefinitelyTyped, but we run in the opposite issue: they weren’t in sync with the latest releases. We decided anyway to move the definitions to this repo – which I think it is fine, because they don’t require much extra work.

However, @ArcticZeroo is right observing that type definitions here are not a first-class citizen. I usually trust what the TS developers send as PR, and merge the fixes as soon as possible.

(I’m considering to rewrite this project in TypeScript, BTW)

All 7 comments

It looks like in particular, format was being required but didn't actually seem to contribute at all to the day picker working. Adding it allows it to compile again

In addition, importing the DayPickerInput seems to be broken with typescript because it cannot redeclare a default exported variable.

There are many issues right now with the types available in this repository and since the author doesn't wrote them himself, i support the idea of moving them to DefinitelyTyped.

Yep, I don't have any personal experience with writing types for DefinitelyTyped but if the author is up for it I can look into it.

It seems that, as a temporary fix, you can add "skipLibCheck": true to your tsconfig.json compiler options, and errors will be swallowed for anything in node_modules

I'm curious... why should they be moved to DefinitelyTyped? There are many projects that are not written in typescript and maintain their own typings. I would have thought that preferable so that the maintainers can update the typings as they are updating the library. Is it purely a maintenance issue?

@johnjesse In a repo not written in typescript, where the maintainers do not actively maintain typings, moving it to DefinitelyTyped makes the typings optional (and they can be easily replaced by a local declarations file), whereas putting it into the module makes it so that a potentially outdated definition throws typescript errors or is missing information :(

I just came here to report that ts complains when I try to import DateUtils since the typescript defs don't include the utils file. I would also appreciate better TS defs

Type definitions were on DefinitelyTyped, but we run in the opposite issue: they weren’t in sync with the latest releases. We decided anyway to move the definitions to this repo – which I think it is fine, because they don’t require much extra work.

However, @ArcticZeroo is right observing that type definitions here are not a first-class citizen. I usually trust what the TS developers send as PR, and merge the fixes as soon as possible.

(I’m considering to rewrite this project in TypeScript, BTW)

Was this page helpful?
0 / 5 - 0 ratings

Related issues

pmartiner picture pmartiner  Â·  3Comments

brpontes picture brpontes  Â·  6Comments

NikitaSasin picture NikitaSasin  Â·  5Comments

matfork-belatrix picture matfork-belatrix  Â·  5Comments

leiit picture leiit  Â·  6Comments