Typescript Compatibility

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.

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.

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

[aabenoja]

We take pull requests

[jrios]

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]

We take pull requests

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

[Darrken]

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

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.