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 Compatibility #466

Open
ghost opened this issue Aug 11, 2020 · 7 comments
Open

Typescript Compatibility #466

ghost opened this issue Aug 11, 2020 · 7 comments

Comments

@ghost
Copy link

ghost commented Aug 11, 2020

For consuming the library from a Typescript project authors must either turn of some type checking, right a hacky module declaration in a default d.ts file, or write and place definitions files in project themselves.

By creating this issue I am hoping to start a conversation on what may be the best approach, or level of interest, to making the es-components and enclosed packages typescript friendly.

Many javascript packages are now including definition files with the npm package as this prevents any typescript consumers of the lib from having to do anything. Also, the declaration files provide many benefits to javascript developers within a modern editor like VS Code; such as the benefits gained from writing in-depth JSDoc comments. However, if we include d.ts files in the project then the files would need to be maintained and will create some additional work. Perhaps the work could be done via an additional tool and script.

Another option may be to create and host a separate definitions package that can place the typescript definitions in the traditional node_modules/@types/library-name/ directory. This strategy has it's own drawbacks and seams like it may be more difficult to maintain versioning. Also, hosting may require some thought as installing may be different then just executing npm i -D @types/es-components as when hosted in http://definitelytyped.org/ .

Currently, we are placing created typescript definition files in our project for the theme packages and are writing declaration for the es-components package now. This ensure the Typescript experience is even throughout the code base.

@ghost
Copy link
Author

ghost commented Oct 2, 2020

I created a repo where a complete Typescript re-write was done in order to produce the highest quality typescript definitions.

https://github.mktp.io/tosimpe/es-components-types

The Types folder contains all declarations for all the es-componenets libraries.

If possible, this folder could be shipped via npm with the library beit the package.json file is updated with the types property.

This would ensure nothing must be done after installing the module to make it typescript compatible. Also, I believe the developer experience in both a javascript env as well typescript env dramatically is improved. Consumers will see all the documentation directly in there editor as opposed to navigating to it in their browser. And all expected types are discoverable in the editor as well.

@ghost
Copy link
Author

ghost commented Oct 2, 2020

@jrios @stevematney @Darrken @aabenoja Is there someone I can talk to about this?

@aabenoja
Copy link
Contributor

aabenoja commented Oct 2, 2020

We take pull requests

@jrios
Copy link
Contributor

jrios commented Oct 2, 2020

If there is consensus, we can definitely see about migrating the repo to typescript. I see that you've done a large part of the work already in the repository you linked above. I think it would be foolhardy to try and do one fell swoop replacement, but if you'd like to see about introducing typescript for a single component, we can test it out before moving more in more of them.

How does that sound? @Darrken @stevematney @aabenoja @tosimpe

@jrios
Copy link
Contributor

jrios commented Oct 2, 2020

We take pull requests

@aabenoja this is not very constructive. let's try and keep things constructive here.

@Darrken
Copy link
Collaborator

Darrken commented Oct 2, 2020

That sounds like a good plan, @jrios. I'd also feel more comfortable with piecemeal conversions rather than one huge PR.

@ghost
Copy link
Author

ghost commented Oct 2, 2020

I will be very busy through the end of the year else I would certainly offer up PR's. I wanted to get a feeling for interest before considering that though.

Currently, We are using patch-package with a npm post install script to include all the Typescript declarations into the node_modules/es-components/ and node_modules/es-components-wtw-theme directories. This ensures our project is fully typesafe and all the documentation for es-components can be found in editor.

I would not recommend a single PR either. The conversion repo I did was just to get the declarations and I made some shortcuts while converting js to ts that would break some of it. The repo does however contain proper JSDOC comments for most components though so even if go no TS route, I think there is a mass benefit to grabbing those from my personal repo.

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

3 participants