[deleted]
Tsdocs.dev: Type docs for any JavaScript library
31–39 of 39 posts
Re: Tsdocs.dev: Type docs for any JavaScript library
#32For me, its stuck at Installing package and extracting docs...
with a nice toaster GIF
Re: Tsdocs.dev: Type docs for any JavaScript library
#33Author here: 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. tsdocs.dev helps you check the API surface of a good number of JS libraries and their past versions — usually a quick search away. There's something powerful about speed and being able to answer questions in seconds that usually take minutes. edit: The se…
I attempted to build this a number of years ago but quickly got frustrated with the inconsistency of how packages are laid out and the unreliability of the information in package.json. Good job if you sorted it out though.
Re: Tsdocs.dev: Type docs for any JavaScript library
#34Awesome. What do you think about this long standing Typescript issue? https://stackoverflow.com/questions/57683303/how-can-i-see-t...
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...
Even I get tired of control clicking up and down hierarchies trying to build a mental model of exactly what's expected.
It's amazing to me that this issue has been ignored so long by the TypeScript team.
Re: Tsdocs.dev: Type docs for any JavaScript library
#35Awesome. What do you think about this long standing Typescript issue? https://stackoverflow.com/questions/57683303/how-can-i-see-t... 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... Even I get tired of control clicking up and down hier…
As far as I know you get something like that with Zod.
The inferred static types don't have names anymore, they just include the resulting types.
Re: Tsdocs.dev: Type docs for any JavaScript library
#36This looks great.
It's a little bit confusing comparing these docs vs "official ones".
Consider:
https://tsdocs.dev/docs/tonal/5.1.2/interfaces/_internal_.Ch...
https://tonaljs.github.io/tonal/module-Chord.html
There seem to be things missing from each.
Re: Tsdocs.dev: Type docs for any JavaScript library
#37Earlier quoted context omitted.
Hey, Leo from Deno here. We recently released a static HTML documentation generator via our `deno doc` subcommand. We also have a similar system for our registry (here an example: https://deno.land/std@0.209.0/http/mod.ts?s=Server ). But we have an outdated system for general use, which is similar to what you have built: https://doc.deno.land/ . Did you know about this, and did you want to built your own system regar…
Cool, fwiw I didn't know about the general use and I use deno heavily, here's a comparison of Three.js: Deno Doc: https://doc.deno.land/https://esm.sh/v135/@types/three@0.159... TSDocs.dev: https://tsdocs.dev/docs/three/0.159.0/modules.html The search UX and documentation UI of TSDocs is better. The availability of Deno is better atm. Though TSDocs was speedier and a better flow when it was working.
yes, the doc.deno.land is relatively outdated and uses an old system. our static generator via the doc subcommand and registry are the newer systems
Re: Tsdocs.dev: Type docs for any JavaScript library
#38> 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.
I was hoping it would work with libraries that don't ship with types.
Re: Tsdocs.dev: Type docs for any JavaScript library
#39This 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? https://docs.oracle.com/javase/8/docs/technotes/tools/window... https://dotnet.github.io/docfx/ 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…
The direct relative tool to javadoc/docfx is Typedoc [1], which this tsdocs.dev hosts (a fork of). The benefits tsdocs.dev adds on top of Typedoc are the ability to open any arbitrary npm package (plus some smarts for @types/ package redirects) inside a hosted Typedoc whether or not that package's own docs site includes a Typedoc view or not.
I use (Markdown plugin versions of) Typedoc output in some of my packages' docs sites. It is a handy tool and I know some users appreciate having it built with the other docs. I'm also personally equally likely to jump directly to a declaration file rather than pull up a documentation site, but I appreciate things like Typedoc when I do find them on other projects' documentation sites, and I appreciate tsdocs.dev for giving a way to further do it for arbitrary packages that don't include it, even if in many cases that won't be the first tool I use for the job because I'm comfortable enough directly in declarations files.
(Also, you mention a good decompiler, its important to remember that Typescript declaration files generally aren't decompiler artifacts and may be inaccurate to the code actually running. I'm more likely to trust a package that generates its own Typedocs in their documentation as that implies they keep their declarations up to date and/or write their library in Typescript directly. In other sorts of projects for me sometimes the next jump from the declaration file is to the source files. I've PRed a lot of declaration file fixes over the years.)