Gathering detailed insights and metrics for docusaurus-plugin-typedoc-api
Gathering detailed insights and metrics for docusaurus-plugin-typedoc-api
Gathering detailed insights and metrics for docusaurus-plugin-typedoc-api
Gathering detailed insights and metrics for docusaurus-plugin-typedoc-api
@apify/docusaurus-plugin-typedoc-api
Docusaurus plugin that provides source code API documentation powered by TypeDoc.
@jiereal/docusaurus-plugin-typedoc
A Docusaurus v2 plugin to build API documentation with TypeDoc.
@mpetrunic/docusaurus-plugin-typedoc-api
Docusaurus plugin that provides source code API documentation powered by TypeDoc.
@memlab/memlab-docusaurus-plugin-typedoc
This is a fork of docusaurus-plugin-typedoc
npm install docusaurus-plugin-typedoc-api
Typescript
Module System
Min. Node Version
Node Version
NPM Version
docusaurus-plugin-typedoc-api@4.4.0
Published on 08 Sept 2024
website@0.6.0
Published on 08 Sept 2024
docusaurus-plugin-typedoc-api@4.3.0
Published on 02 Sept 2024
docusaurus-plugin-typedoc-api@4.2.1
Published on 04 Aug 2024
website@0.5.2
Published on 04 Aug 2024
docusaurus-plugin-typedoc-api@4.2.0
Published on 11 Feb 2024
TypeScript (92.82%)
CSS (4.8%)
MDX (1.82%)
JavaScript (0.56%)
Total Downloads
234,227
Last Day
141
Last Week
882
Last Month
4,193
Last Year
105,021
72 Stars
311 Commits
28 Forks
6 Watching
6 Branches
12 Contributors
Minified
Minified + Gzipped
Latest Version
4.4.0
Package Id
docusaurus-plugin-typedoc-api@4.4.0
Unpacked Size
482.03 kB
Size
103.11 kB
File Count
281
NPM Version
lerna/7.4.2/node@v20.15.0+arm64 (darwin)
Node Version
20.15.0
Publised On
08 Sept 2024
Cumulative downloads
Total Downloads
Last day
5.2%
141
Compared to previous day
Last week
37.2%
882
Compared to previous week
Last month
-11.5%
4,193
Compared to previous month
Last year
44.1%
105,021
Compared to previous year
A Docusaurus plugin for generating source code /api/*
routes, powered by
TypeDoc.
The plugin has been designed to document your public API by default (anything exported from a package's entry point), so any private, protected, or internal code will not be generated.
typescript
>= v4@docusaurus/core
>= v2.0.0@docusaurus/preset-classic
>= v2.0.0yarn add --dev docusaurus-plugin-typedoc-api
Open your docusaurus.config.js
and make the following changes:
themeConfig.navbar.items
and themeConfig.footer.links
(if
desired).1module.exports = { 2 // ... 3 themeConfig: { 4 // ... 5 navbar: { 6 // ... 7 items: [ 8 // ... 9 { 10 to: 'api', 11 label: 'API', 12 position: 'left', 13 }, 14 ], 15 }, 16 }, 17};
plugins
list. The projectRoot
and packages
options are
required.1module.exports = { 2 // ... 3 plugins: [ 4 [ 5 'docusaurus-plugin-typedoc-api', 6 { 7 projectRoot: path.join(__dirname, '..'), 8 // Monorepo 9 packages: ['packages/example', 'packages/other'], 10 // Polyrepo 11 packages: ['.'], 12 }, 13 ], 14 ], 15};
The following options are available to the plugin:
projectRoot
(string
) - Absolute path to the project root where tsconfig.json
is located.
(Required)packages
((string | PackageConfig)[]
) - List of packages relative to the project root.
(Required)banner
(string
) - Banner message to display at the top of the index page. Supports HTML.changelogName
(string
) - Name of the changelog file within a package. Defaults to
CHANGELOG.md
.changelogs
(boolean
) - Include and render the changelog file from every package. Defaults to
false
.exclude
(string[]
) - List of glob patterns to exclude unwanted packages. This is necessary
when using TypeScript project references.gitRefName
(string
) - GitHub repository ref name to point the API links to. Defaults to
master
.minimal
(boolean
) - Render a minimal layout and reduce the amount of information displayed.
Defaults to false
.packageJsonName
(string
) - Name of the package.json file
. Defaults to package.json
.readmeName
(string
) - Name of the readme file within a package. Defaults to README.md
.readmes
(boolean
) - Include and render the readme file from every package. Defaults to
false
.rehypePlugins
(MDXPlugin[]
) - List of rehype plugins to use for
MDX compilation.remarkPlugins
(MDXPlugin[]
) - List of remark plugins to use for
MDX compilation.removeScopes
(string[]
) - Package scopes and prefixes to remove when displaying the package
name in the sidebar and index. For example, boost
will remove @boost/
and boost-
.sortPackages
((a, d) => number
) - Function to sort the package list in the sidebar and on the
index page. Defaults to alphabetical.sortSidebar
((a, d) => number
) - Function to sort the categories and items within each
sidebar, excluding "Overview" and "Changelog". Defaults to alphabetical.tsconfigName
(string
) - Name of the TypeScript config file in the project root. Defaults to
tsconfig.json
.typedocOptions
(object
) - TypeDoc options
to pass to the compiler. Only supports a small subset of options, primarily around visibility
exclusion.The packages
option has been designed to support multiple packages, with multiple entry points per
package. By default the option accepts a list of strings, where each value is a relative path to a
package folder, and a default entry point of src/index.ts
.
1module.exports = { 2 packages: ['packages/core', 'packages/react'], 3};
However, an object can be provided to customize the entry point. All entry point file paths are relative to the package folder, and support 2 formats:
src/index.ts
.src/
. (This is useful for component
libraries)1module.exports = { 2 packages: [ 3 'packages/core', 4 { 5 path: 'packages/react', 6 // Index only imports allowed 7 // import {} from 'package' 8 entry: 'src/index.tsx', 9 // Deep imports allowed 10 // import {} from 'package/some/nested/file' 11 entry: 'src/', 12 }, 13 ], 14};
When not using deep imports, multiple entry points can be defined by passing a map of objects to
entry
, where each key is a sub-path that can be imported from the package (excluding the index
).
Each entry object requires a path
and a label
, which is used for categorizing and sidebars.
1module.exports = { 2 packages: [ 3 'packages/core', 4 { 5 path: 'packages/react', 6 entry: { 7 // import {} from 'package' 8 index: 'src/index.tsx', 9 // import {} from 'package/client' 10 client: { path: 'src/client.tsx', label: 'Client' }, 11 // import {} from 'package/server' 12 server: { path: 'src/server.tsx', label: 'Server' }, 13 // import {} from 'package/server/test' 14 'server/test': { path: 'src/server/test-utils.tsx', label: 'Server test utils' }, 15 }, 16 }, 17 ], 18};
Index entry points don't require a label, so a file path can be passed directly.
This plugin supports API and documentation linking within source code docblocks via the @apilink
and @doclink
tokens respectively. This works in a similar fashion to
TypeDoc's @link
resolution, but also supports
Docusaurus versioning and routing patterns.
@apilink
When linking to other APIs, you must reference them by class name, function name, property, etc,
instead of the actual /api
route.
1# Maps to /api/<package>/class/Registry#register 2{@apilink Registry.register} 3{@apilink Registry.register | Text to use as the label}
@doclink
When linking to documentation pages, you must reference the article by its URL identifier without
the /docs
prefix.
1# Maps to /docs/commands/setup 2{@doclink commands/setup} 3{@doclink commands/setup | Text to use as the label}
This plugin supports API versioning by piggy-backing off the built-in docs versioning implementation, which is a requirement for this to work correctly.
To begin, version your docs with the built-in command:
1yarn docusaurus docs:version 1.2.3
Once the markdown files are generated, run our versioning command with the same version used previously:
1yarn docusaurus api:version 1.2.3
This will create multiple JSON files in the versioned_docs/version-1.2.3
directory. Be sure to
commit these files to your repo.
When versioning, the current state of your branch will be used as that version's API. To update/regenerate old versions, you'll need to checkout an old commit, re-version, and copy the generated files to the latest branch.
Our API is unable to use the
docsVersionDropdown
navigation type, as it's hardcoded in Docusaurus core. However, you can create a custom version
dropdown like so:
1const versions = require('./versions.json'); 2 3module.exports = { 4 // ... 5 themeConfig: { 6 // ... 7 navbar: { 8 // ... 9 items: [ 10 // ... 11 { 12 type: 'dropdown', 13 to: 'api', 14 label: 'API', 15 position: 'left', 16 items: [ 17 { label: 'Next', to: 'api/next' }, 18 ...versions.map((version, i) => ({ 19 label: version, 20 to: i === 0 ? 'api' : `api/${version}`, 21 })), 22 ], 23 }, 24 ], 25 }, 26 }, 27};
This workaround isn't perfect and may be buggy. Use at your own risk!
When we generate API routes, we also dynamically generate and associate a sidebar with each route. This cannot be overridden, but can be customized with some basic options (like categories and sorting).
If you'd like to reference the generated sidebar in your sidebars.ts
, we write the sidebar to a
file located at .docusaurus/api-sidebar-<id>-<version>.js
. The <id>
token defaults to "default"
and <version>
to "current".
1import apiSidebar from './.docusaurus/api-sidebar-default-current'; 2 3export default { 4 api: apiSidebar, 5};
versioned_docs
(or versions.json
) must contain the generated API JSON files,
otherwise the build will fail.There's another plugin called
docusaurus-plugin-typedoc,
that offers a similar solution. However, there are many differences between that package and this
one, with the biggest being that theirs generates markdown files and /docs/api/...
styled routes,
while ours renders custom React pages with /api/...
styled routes. Some other differences are:
No vulnerabilities found.
Reason
no dangerous workflow patterns detected
Reason
no binaries found in the repo
Reason
Found 7/20 approved changesets -- score normalized to 3
Reason
0 commit(s) and 1 issue activity found in the last 90 days -- score normalized to 0
Reason
detected GitHub workflow tokens with excessive permissions
Details
Reason
no effort to earn an OpenSSF best practices badge detected
Reason
dependency not pinned by hash detected -- score normalized to 0
Details
Reason
security policy file not detected
Details
Reason
license file not detected
Details
Reason
project is not fuzzed
Details
Reason
branch protection not enabled on development/release branches
Details
Reason
SAST tool is not run on all commits -- score normalized to 0
Details
Reason
27 existing vulnerabilities detected
Details
Score
Last Scanned on 2025-01-27
The Open Source Security Foundation is a cross-industry collaboration to improve the security of open source software (OSS). The Scorecard provides security health metrics for open source projects.
Learn More