JSDoc is TypeScript
What “JSDoc is TypeScript” Means
- Pro side: In modern tooling, JSDoc comments are parsed by the TypeScript language service.
- The same engine provides squiggles, IntelliSense, and can be run via
tsc --checkJs. - Many TS features work in JSDoc: generics (
@template), utility types (ReturnType, etc.), conditional/mapped/template literal types,@satisfies,@overload, intersections,@extends, etc. - You can often copy–paste TS type declarations into
@typedefblocks.
- The same engine provides squiggles, IntelliSense, and can be run via
- Counter side: Conceptually JSDoc is “just comments”; using TS tools on it doesn’t make it the same language.
- Analogy: running on Windows doesn’t mean you are “using C++”; JSDoc is a format, TS is a language and type system.
Limitations and Rough Edges of JSDoc
- Some capabilities behave differently or are missing in practice:
@typedeftypes are always exported and can’t be scoped, which pollutes libraries’ public surface and IntelliSense.- Certain combinations of tags (
@callback, generics, arrow functions) are fragile or require non‑obvious workarounds. - Some TS constructs (type‑only imports,
satisfies, complex overload sets, some “extends” patterns, private/internal types) either don’t map cleanly or need.d.tssidecars. - Official
jsdocdoc‑generator does not understand newer TS-style annotations that the TS server accepts. - Several people report that large JSDoc‑typed codebases expose edge cases and poorer DX vs equivalent TS.
Build Step vs “Just JavaScript”
- JSDoc advocates:
- No transpile step for browsers or Node; files run as-is.
- Useful for small or “buildless” stacks (native HTML/CSS, web components, lit‑html, etc.).
- Clearer separation of runtime behavior from static documentation/types.
- TS advocates:
- Once you already bundle/minify/HMR, a TS erase step is trivial cost.
- TS syntax is less verbose and clearer for complex types; better tooling and documentation; easier to manage large projects.
- Node now supports native TS type-stripping; for libraries you often need
.d.tsanyway, which reintroduces a build step for JSDoc users.
Type Safety, Interop, and Philosophy
- Consensus that static typing (via either JSDoc+TS or TS files) is valuable documentation and prevents many classes of bugs.
- Multiple comments stress that types don’t replace runtime validation, especially with external input or JS→TS boundaries.
- Some argue TS and JS feel like different languages in practice; others see JSDoc and TS annotations as two front ends to the same TypeScript type system, chosen based on project size and build‑pipeline tolerance.