Author here:<p>I created this because I found myself peeping inside type declaration files too often, and the only way to do that was by installing the package first.<p>tsdocs.dev helps you check the API surface of a good number of JS libraries and their past versions — usually a quick search away.<p>There's something powerful about speed and being able to answer questions in seconds that usually take minutes.<p>edit: The server might be overloaded with requests as we prime up our caches, but do visit back after HN's done hugging us to death.<p>You can show your support and help cover a part of server costs if this (or bundlephobia.com) saved you time.<p><a href="https://github.com/sponsors/pastelsky">https://github.com/sponsors/pastelsky</a>
A good example of a well documented library is three.js<p><a href="https://tsdocs.dev/docs/three/0.159.0/classes/Bone.html" rel="nofollow noreferrer">https://tsdocs.dev/docs/three/0.159.0/classes/Bone.html</a><p>It’s fun to just read through all of the different entities in the 3D ecosystem, even though I’ve only used it only a couple of times.
Looks like a great initiative – I wish there was a reliable TS/JS equivalent of <a href="https://docs.rs" rel="nofollow noreferrer">https://docs.rs</a> (even considering rustdoc's deficiencies[1]).<p>I went through this exercise recently and so far my experience with trying to produce documentation from a somewhat convoluted TS codebase[2] has been disappointing. I would claim it's a consequence of the library's public (user-facing) API substantially differing from how the actual implementation is structured.<p>Typedoc produces bad results for that codebase so sphinx-js, which I wanted to use, doesn't have much to work with. I ultimately documented things by hand, for now, the way the API is meant to be used by the user.<p>Compare:<p><a href="https://ts-results-es.readthedocs.io/en/latest/reference/api/index.html" rel="nofollow noreferrer">https://ts-results-es.readthedocs.io/en/latest/reference/api...</a><p>vs<p><a href="https://tsdocs.dev/docs/ts-results-es/4.1.0-alpha.1/index.html" rel="nofollow noreferrer">https://tsdocs.dev/docs/ts-results-es/4.1.0-alpha.1/index.ht...</a><p><a href="https://www.jsdocs.io/package/ts-results-es#package-index" rel="nofollow noreferrer">https://www.jsdocs.io/package/ts-results-es#package-index</a><p>[1] <a href="https://github.com/rust-lang/rust/issues/66249">https://github.com/rust-lang/rust/issues/66249</a><p>[2] <a href="https://github.com/lune-climate/ts-results-es">https://github.com/lune-climate/ts-results-es</a>
This is a better looking version of what Java and C# have had for a long time (kudos to the author for that!), is that the inspiration for this tool?<p><a href="https://docs.oracle.com/javase/8/docs/technotes/tools/windows/javadoc.html" rel="nofollow noreferrer">https://docs.oracle.com/javase/8/docs/technotes/tools/window...</a><p><a href="https://dotnet.github.io/docfx/" rel="nofollow noreferrer">https://dotnet.github.io/docfx/</a><p>I saw the author mentioned in another comment that they found themselves peeping inside type declaration files "too often". While I do often use sites generated by the above tools to discover new API's that suit my needs, diving into the actual code using a good decompiler is still my first move, as it is often cheaper than seeking out the documentation online, and it will show me the actual implementation as well. So in my opinion there is no shame in looking inside the declaration files!
Awesome. What do you think about this long standing Typescript issue? <a href="https://stackoverflow.com/questions/57683303/how-can-i-see-the-full-expanded-contract-of-a-typescript-type" rel="nofollow noreferrer">https://stackoverflow.com/questions/57683303/how-can-i-see-t...</a><p>It's been my experience introducing and pushing Typescript at multiple companies that people get lost, frustrated, and then push back because they can't untangle and make sense of type hierarchies in order to satisfy the compiler...<p>Even I get <i>tired</i> of control clicking up and down hierarchies trying to build a mental model of exactly what's expected.<p>It's amazing to me that this issue has been ignored so long by the TypeScript team.
Some quick bits of feedback after a small bit of skimming (between bad gateway errors, sorry for contributing to all the over-traffic):<p>- It would be great to see some of the fields from package.json shown as an overview above/next to the README of packages. The homepage and repository fields in particular are often quite useful to have quick access to. You could pull up npmjs.com directly next to this site, but it might be nice to have it all in one place.<p>- In cases where there is an auto-redirect from package-name to @types/package-name it might be nice to still show the README (and package.json metadata if added) of the original package-name.<p>- Typedoc upstream includes a dark theme and does the prefers-color-scheme auto-setup. This might be nice to have here, too.
Wow it works quite well:<p><a href="https://tsdocs.dev/docs/gojs/2.3.12/classes/Diagram.html" rel="nofollow noreferrer">https://tsdocs.dev/docs/gojs/2.3.12/classes/Diagram.html</a><p>vs the real docs<p><a href="https://gojs.net/latest/api/symbols/Diagram.html" rel="nofollow noreferrer">https://gojs.net/latest/api/symbols/Diagram.html</a><p>Somewhat a problem: The constructor for the class is halfway down the page, and there's no scrollbar!
This is great, bookmarked. I hope we can see this in search results in the future.<p>I started a new job in TypeScript back at the beginning of the year and the lack of standardized library documentation viewing is a surprising gap in the TS ecosystem. This is great, thank you!
This looks great.<p>It's a little bit confusing comparing these docs vs "official ones".<p>Consider:<p><a href="https://tsdocs.dev/docs/tonal/5.1.2/interfaces/_internal_.Chord.html" rel="nofollow noreferrer">https://tsdocs.dev/docs/tonal/5.1.2/interfaces/_internal_.Ch...</a><p><a href="https://tonaljs.github.io/tonal/module-Chord.html" rel="nofollow noreferrer">https://tonaljs.github.io/tonal/module-Chord.html</a><p>There seem to be things missing from each.
> TypeDefinitionResolveError
> Failed to resolve types for this package. This package likely does not ship with types, and it does not have a corresponding package `@types` package from which reference documentation for its APIs can be built.<p>I was hoping it would work with libraries that don't ship with types.
For `@remix-run/react`, I get the following error:<p>UNEXPECTED_DOCS_POLL_FAILURE
500 {"statusCode":500,"error":"Internal Server Error","message":"Cannot read properties of undefined (reading 'changePriority')"}