-
Notifications
You must be signed in to change notification settings - Fork 35
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
Comments
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 If possible, this folder could be shipped via 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? |
We take pull requests |
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 |
@aabenoja this is not very constructive. let's try and keep things constructive here. |
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 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. |
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 executingnpm 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.
The text was updated successfully, but these errors were encountered: