Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

TypeScript type declaration file #9

Open
geopic opened this issue Mar 1, 2020 · 5 comments
Open

TypeScript type declaration file #9

geopic opened this issue Mar 1, 2020 · 5 comments

Comments

@geopic
Copy link

geopic commented Mar 1, 2020

If you want I can write a TypeScript type declaration file for this package so that TS developers can utilise the type-checking feature of the language as they use this package. Let me know if you are interested.

@ljharb
Copy link
Contributor

ljharb commented Mar 1, 2020

That’s what DefinitelyTyped is for.

@geopic
Copy link
Author

geopic commented Mar 1, 2020

I'm just proposing another option @ljharb.

@ljharb
Copy link
Contributor

ljharb commented Mar 2, 2020

Do DT types exist already?

It makes no sense to have a type definition if the project isn’t written in TS, since there’s no reliable way to enforce that the TS type matches the JS file.

@geopic
Copy link
Author

geopic commented Mar 2, 2020

It makes no sense to have a type definition if the project isn’t written in TS, since there’s no reliable way to enforce that the TS type matches the JS file.

Both approaches (having a definition file in the repo vs. having a file at @types/is-primitive) require maintaining. The purpose of a types definition file is to provide types for a library written in JS. Typing a project written in TS which compiles to JS is easier, but most npm packages don't follow that route. In my view it's better to have the definition file as part of the repo as it makes for easier maintainability compared to it being in a different repo, as well as there being less clutter in package.json.

@ljharb
Copy link
Contributor

ljharb commented Mar 2, 2020

I very much don't agree; if there's no way to enforce keeping them in sync in-repo, the main npm package might release v1.2.3 with a type bug, and be forced to release a v1.2.4 with no actual JS-related changes. Separating them frees the two conceptually different products to be released independently.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants