3 ms·

My personal experience as a library developer, who has written my library in JS, not TS ... TS is an excellent choice for a lib dev starting a new project toda

My personal experience as a library developer, who has written my library in JS, not TS ... TS is an excellent choice for a lib dev starting a new project today. I can see the advantages of using TS for the library code - in particular for a library that gets popular and welcomes contributions from other developers. However TS is a nightmare for someone like me who: 1. started writing the library 9 years ago; 2. has let the library get "quite" big; and 3. has only learned to use TS in the past year (for the day job) and is nowhere near to becoming a types expert. I've had experience of people suggesting I rewrite the library in TS. Sometimes those suggestions have been quite 'evangelical' in their tone. As an (essentially) solo developer I just don't have the time, capacity or willingness to do that work - however much the end results might please others. I also understand that having type definitions file for the library's interface is, nowadays, a critical factor if the lib dev wants others to use the library in their projects. But writing a .d.ts file for a large, mature repo to at least help those potential users can quickly turn into a World of Hurt. I know this because I've done that work[1] and I never want to do it again. As much as I know that TS is a Force for Good in the JS coding world, there are days when I detest it! [1] - link to the Scrawl-canvas .d.ts file on GitHub - https://github.com/KaliedaRik/Scrawl-canvas/blob/master/source/scrawl.d.ts https://github.com/KaliedaRik/Scrawl-canvas/blob/master/sour...

oefrha 4y ago
Props to you for doing a painstaking job. After-the-fact .d.ts for large mature libraries usually end up with too many anys, or subtle breakages that necessitate @ts-ignore, or a combination of both.
kupopuffs 4y ago
Interesting. you write your .d.ts file by hand?
- rikroots 4y ago
  Yes. I wrote the entire .d.ts file by hand. I did look at including JSDoc comments in the .js files to define types and function signatures, from which I could then autogenerate TS documentation files. But the results were a mess, and they ruined the existing documentation. Given that documenting the code in a way that allows me to autogenerate doc files (in a format that I like) is paramount, I abandoned that idea. Also, the library's structure just doesn't sit well with my limited understanding of TS and TS definitions. I got the impression from the TS docs that the TS developers really like JS classes, and are not that keen on ES6 modules - which is unfortunate because my library makes heavy use of prototypes, modified by mixin functions. So I hand-wrote a single definitions file in a way that matched as closely as possible the library's structure and preferences. Hopefully that file is enough to give developers some useful tips in their preferred IDE when they use the library in their projects. But I've only tested this in Sublime Text.

oefrha 4y ago

Props to you for doing a painstaking job. After-the-fact .d.ts for large mature libraries usually end up with too many anys, or subtle breakages that necessitate @ts-ignore, or a combination of both.

kupopuffs 4y ago

Interesting. you write your .d.ts file by hand?

rikroots 4y ago
Yes. I wrote the entire .d.ts file by hand. I did look at including JSDoc comments in the .js files to define types and function signatures, from which I could then autogenerate TS documentation files. But the results were a mess, and they ruined the existing documentation. Given that documenting the code in a way that allows me to autogenerate doc files (in a format that I like) is paramount, I abandoned that idea. Also, the library's structure just doesn't sit well with my limited understanding of TS and TS definitions. I got the impression from the TS docs that the TS developers really like JS classes, and are not that keen on ES6 modules - which is unfortunate because my library makes heavy use of prototypes, modified by mixin functions. So I hand-wrote a single definitions file in a way that matched as closely as possible the library's structure and preferences. Hopefully that file is enough to give developers some useful tips in their preferred IDE when they use the library in their projects. But I've only tested this in Sublime Text.