You are right, but I prefer TS to write .d.ts files by itself.
I can agree with you when you say that writing JSDoc can help, but if I have to manage more external files (like .d.ts) I think that development becomes more complex: we already have to manage a lot of "external" files, like linter configuration, babel configuration, prettier configuration ... having to manually handle TWO files (js and .d.ts) for each js files I write to avoid compilation (and remembering to update the .d.ts file every time I update a method signature or type) doesn't make much sense (to me, at least) especially considering that 99% of the time, the compilation phase is transparent to the developer thanks to tools like next.js or tsc --watch.
but I prefer TS to write .d.ts files by itself
This is totally fine, and is a preference
I think that development becomes more complex: we already have to manage a lot of "external" files, like linter configuration, babel configuration, prettier configuration
This I disagree with, if anything, skipping typescripts compilation step/avoiding TS source code simplifies development.
Remembering to update the .d.ts file is a non-issue, because if your .d.ts file is not up to date, you'll get the tsc feedback either in your editor or terminal.
The only time you absolutely 100% need feedback is in CI. Having it in your editor is a bonus, albeit one that I can’t see myself living without very easily.
Simplified development is a subjective statement.
My simplified development is having my type annotations inlined in my source code. Your simplified development is having a source code file and a separate manually maintained d.ts file and writing some of those (not all) types twice - once in the d.ts and then once in the JSDoc string
This JSDoc sounds really cool, and I now know, thanks to this article about all the capabilities of JSDoc.
If compilation was somehow a thing I wanted to avoid, I’d use this. But that’s not been my experience. The sourcemap drawback is true, but it’s a pretty minor one given all the tooling that spits this stuff out for you without requiring you to write/maintain extra stuff manually
Some comments have been hidden by the post's author - find out more
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
You are right, but I prefer TS to write .d.ts files by itself.
I can agree with you when you say that writing JSDoc can help, but if I have to manage more external files (like .d.ts) I think that development becomes more complex: we already have to manage a lot of "external" files, like linter configuration, babel configuration, prettier configuration ... having to manually handle TWO files (js and .d.ts) for each js files I write to avoid compilation (and remembering to update the .d.ts file every time I update a method signature or type) doesn't make much sense (to me, at least) especially considering that 99% of the time, the compilation phase is transparent to the developer thanks to tools like next.js or tsc --watch.
This I disagree with, if anything, skipping typescripts compilation step/avoiding TS source code simplifies development.
Remembering to update the .d.ts file is a non-issue, because if your .d.ts file is not up to date, you'll get the tsc feedback either in your editor or terminal.
The only time you absolutely 100% need feedback is in CI. Having it in your editor is a bonus, albeit one that I can’t see myself living without very easily.
Simplified development is a subjective statement.
My simplified development is having my type annotations inlined in my source code. Your simplified development is having a source code file and a separate manually maintained d.ts file and writing some of those (not all) types twice - once in the d.ts and then once in the JSDoc string
This JSDoc sounds really cool, and I now know, thanks to this article about all the capabilities of JSDoc.
If compilation was somehow a thing I wanted to avoid, I’d use this. But that’s not been my experience. The sourcemap drawback is true, but it’s a pretty minor one given all the tooling that spits this stuff out for you without requiring you to write/maintain extra stuff manually