I have the same philosophy when it comes to bundlers and transpilers.
With the browsers developer tools being so awesome a debugging (and prototyping) environment, I feel having a 1:1 with what I write and the devtools is very strong. I know source maps can mitigate some of this, but for me it's more of a hassle than a benefit.
Anyway, great write up! I have linked to this post in my own recent post (shameless plug incoming) about documenting a callback: blog.birk-jensen.dk/documenting-a-callback-functi…
While I wholeheartedly agree with you on Tailwind vs modern CSS, this is different case.
All the functionality you are using via JSDocs is enabled and implemented by TypeScript compiler (probably the one built-in into Visual Studio Code?). Using JSDocs gives you only the advantage that you don't have to transpile source files.
But, since you are already using ESBuild for minification and source-maps, you could have used TypeScript syntax, instead of JSDocs as well. Also, your
jsconfig.jsonis derivate oftsconfig.json.There is a nice post from Rob Eisenberg how to integrate full TypeScript compiler with ESBuild: "An ESBuild Setup for TypeScript"
Also, if you follow trends, NodeJS can now execute TypeScript files out of the box. For example:
node --experimental-strip-types build/copy-files.mts. Even ESBuild can handle "simple" TypeScript files without a full TypeScript compiler.But the point you are right about - mapping types, npm packages, etc... can become quite complicated. Specially because NMP/Node support multiple standard and non-standard JavaScript module types.
So, unlike Tailwind, TypeScript has usefull functionality that does not exist in native JavaScript. And it seems that all the industry is converging on idea that some kind of type notation should exist in JavaScript natively.