It might have just received the hug of death. Otherwise, this is fantastic; I've been looking for something like this.
Should get those bytes on a CDN!
Tsdocs.dev: Type docs for any JavaScript library
11–20 of 39 posts
Re: Tsdocs.dev: Type docs for any JavaScript library
#12This is awesome! Thanks for sharing.
Re: Tsdocs.dev: Type docs for any JavaScript library
#13This is great, bookmarked. I hope we can see this in search results in the future.
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!
Re: Tsdocs.dev: Type docs for any JavaScript library
#14This 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 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!
Re: Tsdocs.dev: Type docs for any JavaScript library
#15Author 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…
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.
Re: Tsdocs.dev: Type docs for any JavaScript library
#16Author 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…
There isn't a LICENSE file in the repo.
Can you add one?
Re: Tsdocs.dev: Type docs for any JavaScript library
#17Author 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…
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.
Re: Tsdocs.dev: Type docs for any JavaScript library
#18A good example of a well documented library is three.js https://tsdocs.dev/docs/three/0.159.0/classes/Bone.html 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.
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.
Re: Tsdocs.dev: Type docs for any JavaScript library
#19Author 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…
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…
> 1. Track re-exports and cross-package references
This should already be tracked — play around with the member visibility widget on the sidebar for e.g. For convenience, I've inlined the types from re-exports, but might be a good idea to indicate they were re-exported.
Pointing to the canonical source can also limit the usefulness in a few cases (e.g. d3 is just a bunch of re-exports), and users may not care about internal package organization.
> 2. consider supporting the @packageDocumentation tag Organizing by @category and @packageDocumentation should already be supported. e.g. See the functions in — https://tsdocs.dev/docs/lodash-es/4.17.21/index.html
> 3. Relative links to things like CONTRIBUTING.md currently break Yeah, this is known, thanks! https://github.com/pastelsky/tsdocs/issues/9
Re: Tsdocs.dev: Type docs for any JavaScript library
#20Author 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…
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…
[deleted]