This is really awesome work!

This takes a big burden off of individual packages from publishing their own API docs (having done that I know how hard it can be!), and having a centralized API viewer can offer a lot of advantages over separate docs.

A couple of things I would suggest:

1. Track re-exports and cross-package references and allow crossref links to go into other packages. If package A uses rxjs, then links to the rxjs types should go to the canonical definitions in the rxjs package. (figuring out the canonical declaration can be tricky because it's not always the original declaration though)

2. Organizing by type isn't always a great introduction or way to navigate a package. On the Lit project at https://lit.dev/docs/api we re-organized the API docs by categories and the most important API surfaces. There aren't standard jsdocs for this, but a few straightforward things like @category could be used to offer an alternate top-level nav for a package. Also consider supporting the @packageDocumentation tag from tsdoc.

3. Consider showing files other than the README. Relative links to things like CONTRIBUTING.md currently break. Alternatively interpret all relative links as pointing to github.com or npmjs.com. It'd be great to have a way to link from the README into API docs to guide readers. The community doesn't have a great convention for this unfortunately.

Found a fun error "TypeDefinitionResolveError" for a package that includes Typescript sources. Best guess, it may be related to the package.json uses a modern "bare" exports field ("exports": "./index.js"; no "main", no "types") where "index.ts" exists in the package as well. (Not a lot of projects use this today, but it is a modern way to publish projects that will likely increase.)

Typescript itself works just fine with this with this type of package with "moduleResolution": "node" (tsconfig/CLI options) with recent version using recent enough ES targets or with "moduleResolution": "node16" in older versions/older ES targets/non-ES targets.

https://tsdocs.dev/search/docs/butterfloat

Hope that's useful enough to debug the error.

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 regardless, or did you not know about it and would this have been something you would have used instead of creating your own system?

Does this service do anything different/better than jsdocs.io?

I like the way jsdocs.io puts everything on one page.

I was initially confused when I looked up a package on tsdocs.dev and just got the readme. The actual type defs were tucked away out of sight in the hamburger menu. May just be a problem with the mobile site.

This is useful, the search especially.

There's a bug that only happens on this page [1]?

    Uncaught TypeError: Failed to execute 'observe' on 'MutationObserver': parameter 1 is not of type 'Node'

[1] https://tsdocs.dev/docs/svelte/4.2.8/functions/_svelte_compi...

Hi, nice site! I found a small ux issue on ios: the search field has capitalization on by default. It can be turned off with https://stackoverflow.com/a/5171812

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.

Congrats, this looks fantastic and will be useful for many!

There isn't a LICENSE file in the repo.

Can you add one?

Great reference.

To this date, one of the best well-documented code is jQuery: https://github.com/jquery/jquery/blob/main/src/core/init.js

I learned a lot from looking into the code.

Agreed although I'm somewhat confused since the three js source code is JavaScript not TypeScript.

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.)

[1] https://typedoc.org/

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.

> it might be nice to still show the README (and package.json metadata if added) of the original package-name

This would be great, @types/* docs are rarely ever useful. Although it'd be still nice to indicate that the types are not available in the original package.

Should get those bytes on a CDN!

I saw this on twitter a week or two ago and that's exactly how he explained the purpose