pastelsky / tsdocs Goto Github PK

My package can't be analyzed and runs into this error, I'd like to know why so I can try to fix it. Is there a way to read logs or access information about the error somehow? Thanks in advance.

https://tsdocs.dev/search/docs/classy-ink

As in the title, it's poor UX if you don't have these default keys in the normal input.

and too many redirect error

I feel like users are more likely to need documentation for a rather new version of a package and scrolling through all the possible versions doesn't really feel nice.

I'm willing to submit a pr for this change.

Searching for "align" in the react-window types does not find this page! https://tsdocs.dev/docs/react-window/1.8.10/types/Align.html

I would like to suggest a new feature for TSDocs.dev that enhances the sharing capabilities of NPM package documentation.

Currently, when sharing a link to a specific NPM package's documentation, the visibility settings for members are always set to default.

It would be incredibly useful to have the ability to embed custom visibility settings directly into the URL.

Often, when an NPM library extends another, it inherits methods and properties that may not be relevant to the immediate documentation needs. The ability to share links to these packages with URL parameters that hide or deemphasize inherited methods and properties would be extremely valuable.

This would allow NPM package authors to share their documentation with more focus on their package's unique features, while reducing emphasis on inherited aspects

It could be implemented via URL parameters that dictate the visibility settings, providing a seamless and efficient way to share documentation with specific configurations.

when I search for "React" on tsdocs, It only shows the following error：

https://tsdocs.dev/search/docs/discord-api-types fails with a TypeDefinitionResolveError, probably because the package doesn't actually expose top-level exports. It does however specify exports in its package.json. It would be cool if eg. https://tsdocs.dev/search/docs/discord-api-types/v10 worked

Package - @mantine/[email protected] and all @mantine/core

Upon publishing a new version of an npm package, it seems like initial versions of the package take a while to build before they're cached. For example, when https://tsdocs.dev/docs/ts-api-utils/1.2.0 was released just now, on visiting https://tsdocs.dev/docs/ts-api-utils for the first minute or it would stall and maybe eventually give a Cloudflare 524 timeout. Now both pages are working fine.

Separate from speeding up the package builds (#44): could the site immediately give a 'loading' page while the package version is building?

Per example at: https://tsdocs.dev/docs/@liveryvideo/player/7.9.0-beta.4/classes/LiveryPlayer.html deselect the Inherited member visibility and then scroll down to see empty sections for Methods - attributes, Methods - controllers, etc. I think these are derived from usage of @group in the tsdoc of the LitElement from the lit package that is extended here. These sections do have members while Inherited members are enabled, but after that is disabled they are empty.

👋 I found this project recently and think it's awesome. Really nice way to solve the issue of TypeDoc-ing packages. Yay! Thanks for making it!

I separately filed #44 and #45 around improving the cold start experience for new packages. But even if those two get improved, it's likely that larger packages will inevitably take a while to build on each new version. Could tsdocs provide a recommendation around how packages should handle "priming" the cache on new package release?

For example, could a copy-and-paste script (or published GitHub Action) be added to the docs that pings https://tsdocs.dev/docs/<package-name> as a part of a release flow?

just opening https://tsdocs.dev/ gives this error in ARC Browser(Not tested on other browsers)

I feel adblocker is causing this, but still without ad blocker css seems to be missing

Clearing cache is not helping

I tried to pull up the information for nano-cache and received the following error:

    ENOSPC: no space left on device, copyfile '/var/www/tsdocs/tsdocs/node_modules/typedoc/static/main.js' -> '/var/www/tsdocs/tsdocs/docs/1.0/nano-cache/1.1.2/assets/main.js'
at Object.copyFile in node:internal/fs/sync:49
at Object.copyFileSync in node:fs:2949
at copySync in typedoc/dist/lib/utils/fs.js:175
at  in typedoc/dist/lib/utils/fs.js:171
at Array.forEach in :null
at copySync in typedoc/dist/lib/utils/fs.js:171
at _classThis.onRenderEnd in typedoc/dist/lib/output/plugins/AssetsPlugin.js:112
at triggerEvents in typedoc/dist/lib/utils/events.js:191
at triggerApi in typedoc/dist/lib/utils/events.js:167
at eventsApi in typedoc/dist/lib/utils/events.js:60

I've been stuck here a while, it might just help to say how long it'll take! Thanks for the open source tool, nice work.

Here are a few pieces that we currently need help with

1. Getting a good pre-commit setup, and CI steps
2. Making our styling system saner (currently its a mix of hardcoded values, and CSS vars. Also, the typedoc styles live separate to the next JS App)
3. Dark mode support for docs (#1)
4. Doing a coverage of the top ~200 most used frontend / backend npm packages by type and seeing where tsdocs.dev fails
5. A Command + K search widget for quick search

I think it would be very cool, if I have a package and I want to have a really quick API docs in my application

so it would be cool if there's smth like that

what do you think? @pastelsky

Trying to access @hilma/forms results in the site crashing.

The first few times I tried to access it, it resulted in an UNEXPECTED_DOCS_POLL_FAILURE:

Refreshing the page led to this:

I tried again a few minutes later and got a different failure, with this stack trace:

Accessing other libraries works fine (I looked at the docs for react and eslint-plugin-nitpick which is my own package and didn't encounter any error).

I don't know if this issue is the proper way to report this, but help would be appreciated...

For example: https://tsdocs.dev/docs/rpc-anywhere/1.2.0/index.html#md:features-under-consideration

The OpenSearch description format can be used to describe the web interface of a search engine. This allows a website to describe a search engine for itself, so that a browser or other client application can use that search engine. OpenSearch is supported by (at least) Firefox, Edge, Safari, and Chrome. (See Reference Material for links to other browsers' documentation.)
– https://developer.mozilla.org/en-US/docs/Web/OpenSearch

e.g. PR: kachkaev/njt#45
e.g. https://njt.vercel.app/opensearch.xml

PS: might look into implementing this in the next weeks

you can add an API route like /api/og?name=foo to generate og images because it's much better for sharing tsdoc URLs across the platforms.

From HN:

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.

Hey ! I just got a 502 error on the tsdocs.dev website

My project, RPC Anywhere, exports a class that has the standard constructor, and two alternative constructors in the form of static methods (asClient and asServer). I've noticed that these show up as normal methods instead of in the constructors section, so I'm wondering how tsdocs detects these? Thanks in advance.

Link to docs: https://tsdocs.dev/docs/rpc-anywhere/1.2.0/classes/RPC.html#constructor

First, thank you very much for this website! <3 This looks very promising and I think it has a lot of potential.

I noticed that there isn't a way to access subpath exports. For example, solid-js has a few subpath exports like render or Portal from solid-js/web. It seems that there isn't a way to look at the types of these exports.

Link to solid-js on tsdocs.dev: https://tsdocs.dev/docs/solid-js/1.8.7

Upon publishing a new version of an npm package, it seems like initial versions of the package take a while to build before they're cached. For example, when https://tsdocs.dev/docs/ts-api-utils/1.2.0 was released just now, on visiting https://tsdocs.dev/docs/ts-api-utils for the first minute or it would stall and maybe eventually give a Cloudflare 524 timeout. Now both pages are working fine.

Separate from giving a better response while the build is happening (#45): are there opportunities to speed it up?

(btw, I do see #28 (comment) - just filing an issue to ask about & track this 🙂)

Would be cool to have a dark mode or multiple themes to be chosen by each user.

Similar to https://doc.rust-lang.org/book/ where we have multiple color themes.

I noticed this issue when I was viewing the docs for the xstate package and tried to search using the top input for the @xstate/react package. The slash switches focus to the other input before you can finish typing.

Cool project btw!

https://tsdocs.dev/search/docs/react-leaflet

Is there a way to use tsdocs from the command line to extract info from source code and output it as (for example) JSON?

I'm looking for tools that would allow me to bring support for TypeScript in mkdocs/mkdocstrings.

Currently it seems like this is just a service. I do see mention of running it locally, but then you need to install redis as well. And also I imagine it will also only work with published NPM packages.

I want a way to preview what the generated documentation will look like while I'm working on my code, before publishing it.

E.g. something like a tsdocs-preview NPM package that you can add as a dev dependency to your project to be able to run a server that shows you the docs generated based on the files in your local repo checkout.

Or perhaps it would be even better if there was like a tsdocs-cli NPM package that enables you to locally generate the related HTML etc or perhaps even alternatively MD. That way that could alternatively also be included within NPM packages. But also it would enable previewing your tsdoc based documentation.