Starlight plugin to generate documentation from TypeScript using TypeDoc
Home Page: https://starlight-typedoc.vercel.app
License: MIT License
Want to get started immediately? Check out the getting started guide.
A Starlight plugin using TypeDoc and typedoc-plugin-markdown to generate documentation from TypeScript code.
Check out the example for a preview of the generated documentation.
Some TSDoc tags uses a custom Markdown syntax, e.g. the @deprecated, @alpha, @beta and @experimental tags using Starlight asides:
Licensed under the MIT License, Copyright © HiDeoo.
See LICENSE for more information.
If I add typedoc-plugin-markdown 4.0.0-next.43, I'm getting a couple of errors in node_modules/starlight-typedoc/libs/theme.ts, and also astro complains that browsers APIs are being used in server.
The latest that seems to work is 4.0.0-next.38
yarn devstarlight-typedoc is compatible with latest version of typedoc-plugin-markdown
Every time
No response
No response
When a base is set in the astro config, the internal links between pages no longer work, as they don't include the base.
baseThe link should work and take me to the correct site instead of the 404 page.
Every time
"@astrojs/starlight": "^0.15.0",
"astro": "^4.0.0",
"sharp": "^0.33.0",
"starlight-typedoc": "^0.6.0",
"typedoc": "^0.25.4",
"typedoc-plugin-markdown": "^4.0.0-next.37",
"typedoc-plugin-mdn-links": "^3.1.8"here the repo that i have the problem in.
To get this running you need to also clone the submodule and install the submodules deps. (The submodule uses bun and the docs uses npm. It's kind of a mess 😅.)
In entryPointStrategy=packages, each package has its own config. Only some of those “root” options affect how the individual packages are built (e.g. plugins). But it is certainly not a straightforward “inherit from root config” situation.
Essentially, that means that many/most/all settings in the typeDoc prop of the starlight-typedoc options object are ignored. Since it acts as the root config, and inheritance doesn’t happen, the settings do nothing.
(I would expect typedoc to have better documentation around this, or a config system that makes more sense, but I digress)
typeDoc prop and set a config value to something obvious like disableSources=trueIt’s likely not feasible to do anything about this other than note it in the documentation.
Every time
No response
No response
The generated links by typedoc have the interfaces/types/etc... in the casing they are present in the source code and also have the extension (.md), meanwhile in starlight the paths are all normalized (lower cased) and do not have the .md extension present, this makes it so the links just do not work and redirect to 404.
I have also noticed that if typeDoc.publicPath is not the same as the output the links will redirect to the base domain which also results in 404.
1- have the following:
// A.ts
import type { B } from "./B";
export interface A {
a: string;
b: B
}
// B.ts
export type B = number | bigint2- Use createStarlightTypeDocPlugin() and pass A.ts as your entry point to function returned.
I would expect the links to just work but they dont and i havent found any work around.
Every time
No response
Doing some local dev against the latest in https://github.com/tgreyuk/typedoc-plugin-markdown and was getting this error:
Tried to set an option (hideKindPrefix) that was not declared.
This has been removed in typedoc2md/typedoc-plugin-markdown@0271ed1
Looks like the plan is to remove hideKindPrefix and replace it with titleTemplate:
Develop a project using the next branch of typedoc-plugin-markdown as of typedoc2md/typedoc-plugin-markdown@0271ed1#diff-f2c035f40366f0be066f365fe4f0e9abc4b5b16c903898aab4800de8ec158c7f
You'll then see the error in the console.
Shouldn't error
Every time
No response
Not currently an issue and it doesn't result in a failure, but most likely will affect the output and also adds a bunch of log clutter.
Currently, all files are located under the top-level section in the sidebar and they are displayed with their file paths as names. With lots of files in different folders, it can be quite difficult to find a specific file.
It would be nice if there was an option to have sub-folders in the sidebar that mimic the file structure of the source that the docs are generated for.
No response
How it currently looks:
How the folder structure looks:
how my typedoc entry point config looks:
https://github.com/mProjectsCode/obsidian-js-engine-plugin-docs/blob/a608858585f9dcf6e58b5ec46a7306e8f2311722/astro.config.mjs#L5
I am generating a documentation using typedoc and the markdown plugin. But I'm getting broken links.
As you can see here
As you can see there is a /classes route which is making the links to broke. I want so to develop a function which edits the url to remove that unecessary route.
Use the typedoc starlight plugin.
In the astro config file put the function which call for the plugin
chatbotTypeDoc({
entryPoints: ['./twitchapi/packages/chatbot/src/index.ts'],
tsconfig: './twitchapi/packages/chatbot/tsconfig.json',
output: 'api/chatbot',
typeDoc: {
useCodeBlocks: true,
parametersFormat: "table",
propertiesFormat: "table",
enumMembersFormat: "table",
typeDeclarationFormat: "table",
indexFormat: "table",
expandParameters: true
}
})Then the md broken links that reference other classes or structures are broken
Links aren't broken and redirect to an existing md file
Every time
No response
Using starlight-typedoc only allows for a single instance in a astro project since v0.7.0. This means that if you want to document two different entries point separately, you can't anymore since the plugin allow for a single entry in the menu and a single plugin configuration.
Instead of exporting the plugin and the symbol for injecting the menu, we could also expose a plugin creator that can create a new token on the fly so that we can have multiple instance of the same plugin in a single starlight docs
Doing multiple starlight that are stitched at build time somehow
No response
Hi. I'm pretty new to Astro so this may be a configuration issue but I wanted to open this just in case.
The Drupal API Client project just published docs built with Starlight and the TypeDoc plugin (thanks for this btw!). We noticed a few links are 404ing, specifically it seems like ones generated by typedoc {@link} tags. These particular ones are after a @see tag, but I see this behavior for other links too.
See https://project.pages.drupalcode.org/api_client/api/drupal-api-client/api-client/classes/apiclient/
See, "ApiClientOptions" or "BaseUrl".Expected: the link takes you to the correct page
Actual: 404
Other links on that page seem to work fine. Here is an example of what the links look like in the plain markdown:
[ApiClientOptions](../type-aliases/ApiClientOptions.md) and [BaseUrl](../type-aliases/BaseUrl.md)The other links do not have the file extension and the last part of the path is all lowercase. It also seems the links don't go up enough levels. ../../type-aliases/apiclientoptions/ works in this case.
Every time
Reproducible locally on m2 macbook. The site linked above is built in GitLab CI.
Here is our config:
starlightTypeDoc({
entryPoints: ["../packages/*"],
output: "api",
tsconfig: "../tsconfig.json",
typeDoc: {
entryPointStrategy: "packages",
plugin: ["typedoc-plugin-mdn-links"],
useCodeBlocks: true,
navigationLinks: {
"Project Page": "https://www.drupal.org/project/api_client",
},
},
}),Link to the repo if you are interested: https://git.drupalcode.org/project/api_client
I m trying to get external source links from my documentation to github, and i specified that using the typeDoc options:
starlightTypeDoc({
entryPoints: ['./node_modules/fabric/fabric.ts'],
tsconfig: './node_modules/fabric/typedoc.config.json',
typeDoc: {
plugin: ['typedoc-plugin-no-inherit'],
readme: 'none',
gitRemote: 'https://github.com/fabricjs/fabric.js/blob',
gitRevision: 'v6.0.0-beta20',
entryFileName: 'index.md',
includeVersion: true,
sourceLinkExternal: true,
sourceLinkTemplate: 'https://github.com/fabricjs/fabric.js/blob/{gitRevision}/{path}#L{line}',
},
}),
The links i get in my documentation is always relative:
While i would like to have a link to the repo and file of that part of source code.
I see a link to github as specified in the template
Every time
No response
No response
This is arguably a Starlight issue instead. If it's fixed in Starlight, this package may be able to safely ignore it.
If we use the @group tag to define a custom group, this becomes an instance of ReflectionGroup. The thing is: not all ReflectionGroups have an associated directory.
AFAICT, typedoc-plugin-markdown only creates directories for its blessed groups: classes, functions, interfaces, type-aliases, variables. "Custom" groups are shown only as a heading within the index.md; each item within the group links to the whatever of these is appropriate. For example:
// MyError.ts
/** @group Errors */
class MyError extends Error {
}This will show the MyError item within an Errors group in an index.md, and it will link to ./classes/MyError.md. There is no ./errors/MyError.md.
So, while Starlight has some work to do, this package may be able to avoid the problem altogether.
One way it could be solved is to create a list of the "blessed" group names typedoc-plugin-markdown uses, and only output an autogenerate sidebar item if the group title is within that list.
Another is to actually check the filesystem, I suppose.
This should be reproducible at this commit: boneskull/midnight-smoker@619ee95
lmk if it isn't. It's pretty easy to reproduce, anyway; I don't think it needs a packages entryPointStrategy, so it may be reproducible on a simple project.
Don't make the group if it's empty.
Every time
all new awesome versions of stuff & things
No response
Improves DX when wanting to use some of the typedoc-plugin-markdown options in the typeDoc config object. Right now there's no completion for this.
Import plugin options from typedoc-plugin-markdown:
import type { PluginOptions } from 'typedoc-plugin-markdown'Union that with the typeDoc config here:
No response
No response
When using {@link} in the summary block (outside of one of the custom-handled depreciation tags) then it will output the incorrect URL.
You've tested this in the fixtures but only in the context of a @depricated tag:
When using it outside then it results in an invalid URL: https://github.com/lorenzolewis/starlight-typedoc/blob/74acb18161544b6252fd395a880fd09bf2ffd5e3/fixtures/src/functions.ts#L27
The logic path upstream goes to this point from what I can tell: https://github.com/tgreyuk/typedoc-plugin-markdown/blob/ace1b92284a6575141c3ce6d15a8fd7c3813b0e6/packages/typedoc-plugin-markdown/src/theme/resources/partials/comment.parts.ts#L30
However it seems that context.relativeURL isn't taking the overridden property. So I'm not 100% sure if this is an issue with upstream and if it is I'm not sure how it would be fixed as everything else that references links seems to be pulling it correctly.
See this commit: lorenzolewis@2051951
This branch has starlight-links-validator added to it to automate checking.
This should use the overridden relativeURL method.
Every time
No response
This repro is using since this is what's in the example folder "typedoc-plugin-markdown": "4.0.0-next.16", but I can confirm the same is happening in next.17 but haven't checked against next.18 as it's broken a few things for me unrelated to this.
I'm trying to add a Generated badge to my API docs section, and it doesn't seem to work. (Using the spread operator):
sidebars: [
{
...typeDocSidebarGroup,
badge: {
text: 'Generated',
variant: 'note',
},
},
// ...
]An option within StarlightTypeDocOptions with the badge parameters from @astrojs/starlight would be nice. (like being able to set the sidebar as collapsed)
Would hopefully look like this:
No response
No response
Whenever my friend using a Windows machine uses the project, there is a difference in the generated API docs.
Using MacOS (probably on any UNIX machine), the paths look like /api/namespaces/presence/..., however, on Windows, the paths look like /api/namespacespresence...
Oddly enough, it seems like the URL paths still link to the proper page though?
starlight-typedocThe paths should be the same regardless of OS
Every time
No response
No response
Yes, If I want to have custom gruops or group order I can't (and this is a base TypeDoc feature)
Make this possible
No response
Also doesn't work excludeGroups, I think would be great also has custom groups defined by the user using @group in jsdoc
Versions:
"starlight-typedoc": "^0.11.0",
"typedoc": "^0.25.12",
"typedoc-plugin-markdown": "4.0.0-next.54",
Hi, thank you for making this useful plugin!
I'm having a problem with the generated links missing some '/'.
Have a .ts file that is at least 3 subfolders deep. (src/utilities/environment/index.ts)
├── src
│ ├── utilities
│ │ ├── environment
│ │ │ ├── index.ts
Generate docs
Here you can see the missing '/' in the links generated
Generated links:
http://localhost:4321/.../api/providersenvironmentclasses/default/
Expected links:
http://localhost:4321/..../api/providers/environment/classes/default/
Every time
Processor:
Intel(R) Core(TM) i7-10850H CPU @ 2.70GHz 2.71 GHz
System type:
64-bit operating system, x64-based processor
Browser:
Google Chrome Version 125.0.6422.77 (Official Build) (64-bit)
Perhaps you don't support subfolders?
#21
...or possibly just incompatible with Typedoc v0.52.4.
This is two problems with likely a single root cause.
I have a monorepo with several workspaces, and I use the packages entryPointStrategy to create a single docs site from them. This works when typedoc is run from the command line (with or without typedoc-plugin-markdown@next).
However, this line will always throw an exception with this use case:
This is likely due to a breaking change in how Typedoc creates ProjectReflection files, but I don't know if that's due to the breaking changes in how the packages entryPointStrategy works, or for some other reason. In this use case, groups will always be undefined. I think what you want to get at is deeper in the ProjectReflection.
Once this conditional has been commented out, the plugin proceeds to generate the documentation and place it in the desired output directory. However, the sidebar appears empty (I'm guessing because groups is undefined).
My setup involves a root typedoc config with entryPointStrategy: 'packages', where the entryPoints are relative paths to workspace folders. Each workspace then has its own Typedoc config containing an entryPoint and any other specific configuration.
The configuration for this plugin I'm using is akin to this:
starlightTypeDoc({
entryPoints: [
'../workspace-a',
'../workspace-b',
'../workspace-c',
],
typeDoc: {
entryPointStrategy: 'packages'
},
tsconfig: '../../tsconfig.json',
})These workspaces live in a packages/ folder, and my Astro config is in packages/docs/astro.config.mjs (thus the relative paths).
I'm not sure what I'd expect, exactly. Certainly, I want the sidebar to display something. It might mean extra nesting in the sidebar? Ideally, I'd have some control over how I wanted to arrange things without the need to override a component. Maybe pass in some option to a sidebar configurator which tells it which project to display; I could repeat this for each project.
Every time
No response
I've come across a bug while working with markdown transformation, specifically involving the @link tags. It appears that when these tags are converted to markdown, the resulting link is broken and doesn't function properly. This issue is hindering the functionality of the links within the markdown output, making navigation unreliable.
export interface LinkedInterface {}
/**
* Go to {@link LinkedInterface}
*/
export interface MyInterface {
linkedInterface: LinkedInterface
}
Here is an screenshot about the broken link. As you can see the path to my interface BanOptions is http://localhost:4321/api/chatbot/api/chatbot/interfaces/banoptions and should be http://localhost:4321/api/chatbot/interfaces/banoptions.
The links shouldn't be broken. So http://localhost:4321/api/chatbot/api/chatbot/interfaces/banoptions path should be http://localhost:4321/api/chatbot/interfaces/banoptions.
Every time
starlight-typedoc: v0.11.0No response
I believe typedoc 0.25 will break your build
Try the build, it go boom
It shouldn't go boom
Every time
No response
It should be a relatively easy fix, I did this on our repo which is using essentially the same setup as this: tauri-apps/tauri-docs#1437. Lmk if you'd like me to PR it or if you'd to handle it yourself (not sure how you like to deal with dependency versioning).
I tried to implement this but I found that when using >= next.58 an error is thrown when compiling the code. After finding #29 I reverted back to next.43, but that doesn't take away that this library currently doesn't supported the latest next release.
Repository with this issue: https://github.com/favna/nintendo-switch-eshop
Branch: renovate/all-minor-patch
PR for where this version is pulled in: favna/nintendo-switch-eshop#34
CloudFlare logs:
<html>
<body>
<!--StartFragment--><pre class="c_c c_bw c_mx c_my c_qp c_qq c_de c_rg c_rh c_ri c_rj c_fc c_fd c_qr c_by c_rk" style="box-sizing: border-box; border-radius: 0px; color: rgb(217, 217, 217); display: block; font-size: 12px; margin: 0px; overflow: auto; padding: 16px 32px; width: 1262px; background-color: rgb(29, 29, 29); border-width: 0px 0px 1px; border-style: solid; border-color: rgb(61, 61, 61) rgb(61, 61, 61) rgb(49, 49, 49); border-image: initial; font-family: monaco, courier, monospace; height: 500px; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration-thickness: initial; text-decoration-style: initial; text-decoration-color: initial;">
13:53:07.493 | Cloning repository...
-- | --
13:53:08.192 | From https://github.com/favna/nintendo-switch-eshop
13:53:08.193 | * branch 28d0053ac2a097a6864d877d91c0650fc1635589 -> FETCH_HEAD
13:53:08.193 |
13:53:08.245 | HEAD is now at 28d0053 chore(deps): update all non-major dependencies
13:53:08.246 |
13:53:08.330 |
13:53:08.331 | Using v2 root directory strategy
13:53:08.356 | Success: Finished cloning repository files
13:53:09.901 | Checking for configuration in a wrangler.toml configuration file (BETA)
13:53:09.902 |
13:53:09.902 | Found wrangler.toml file. Reading build configuration...
13:53:09.907 | pages_build_output_dir: dist
13:53:09.907 | Build environment variables: (none found)
13:53:10.018 | Successfully read wrangler.toml file.
13:53:10.108 | Restoring from dependencies cache
13:53:10.125 | Restoring from build output cache
13:53:10.375 | Detected the following tools from environment: [email protected], [email protected], [email protected]
13:53:10.734 | Preparing [email protected] for immediate activation...
13:53:11.367 | Installing project dependencies: yarn
13:53:12.290 | ➤ YN0000: · Yarn 4.1.1
13:53:12.302 | ➤ YN0000: ┌ Resolution step
13:53:12.593 | ➤ YN0000: └ Completed in 0s 292ms
13:53:12.651 | ➤ YN0000: ┌ Fetch step
13:53:29.428 | ➤ YN0013: │ 1200 packages were added to the project (+ 173.08 MiB).
13:53:29.428 | ➤ YN0000: └ Completed in 16s 777ms
13:53:29.488 | ➤ YN0000: ┌ Link step
13:53:37.889 | ➤ YN0007: │ esbuild@npm:0.19.12 must be built because it never has been before or the last one failed
13:53:37.890 | ➤ YN0007: │ esbuild@npm:0.20.2 must be built because it never has been before or the last one failed
13:53:37.890 | ➤ YN0007: │ sharp@npm:0.33.3 must be built because it never has been before or the last one failed
13:53:37.891 | ➤ YN0007: │ esbuild@npm:0.17.19 must be built because it never has been before or the last one failed
13:53:37.891 | ➤ YN0007: │ workerd@npm:1.20240419.0 must be built because it never has been before or the last one failed
13:53:38.570 | ➤ YN0000: └ Completed in 9s 82ms
13:53:38.696 | ➤ YN0000: · Done in 26s 406ms
13:53:38.940 | Executing user command: yarn run build
13:53:41.989 | 11:53:41 AM [vite] Error when evaluating SSR module /@fs/opt/buildhome/repo/node_modules/starlight-typedoc/libs/theme.ts: failed to import "typedoc-plugin-markdown"
13:53:41.989 | \|- SyntaxError: [vite] Named export 'MarkdownThemeRenderContext' not found. The requested module 'typedoc-plugin-markdown' is a CommonJS module, which may not support all module.exports as named exports.
13:53:41.989 | CommonJS modules can always be imported via the default export, for example using:
13:53:41.990 |
13:53:41.990 | import pkg from 'typedoc-plugin-markdown';
13:53:41.990 | const {MarkdownThemeRenderContext} = pkg;
13:53:41.990 |
13:53:41.990 | at analyzeImportedModDifference (file:///opt/buildhome/repo/node_modules/vite/dist/node/chunks/dep-DkOS1hkm.js:54043:19)
13:53:41.990 | at nodeImport (file:///opt/buildhome/repo/node_modules/vite/dist/node/chunks/dep-DkOS1hkm.js:55079:9)
13:53:41.990 | at async ssrImport (file:///opt/buildhome/repo/node_modules/vite/dist/node/chunks/dep-DkOS1hkm.js:54976:24)
13:53:41.991 | at async eval (/opt/buildhome/repo/node_modules/starlight-typedoc/libs/theme.ts:5:31)
13:53:41.991 | at async instantiateModule (file:///opt/buildhome/repo/node_modules/vite/dist/node/chunks/dep-DkOS1hkm.js:55036:9)
13:53:41.991 |
13:53:41.991 | 11:53:41 AM [vite] Error when evaluating SSR module /@fs/opt/buildhome/repo/node_modules/starlight-typedoc/libs/typedoc.ts: failed to import "/@fs/opt/buildhome/repo/node_modules/starlight-typedoc/libs/theme.ts"
13:53:41.991 | \|- SyntaxError: [vite] Named export 'MarkdownThemeRenderContext' not found. The requested module 'typedoc-plugin-markdown' is a CommonJS module, which may not support all module.exports as named exports.
13:53:41.991 | CommonJS modules can always be imported via the default export, for example using:
13:53:41.991 |
13:53:41.992 | import pkg from 'typedoc-plugin-markdown';
13:53:41.992 | const {MarkdownThemeRenderContext} = pkg;
13:53:41.992 |
13:53:41.992 | at analyzeImportedModDifference (file:///opt/buildhome/repo/node_modules/vite/dist/node/chunks/dep-DkOS1hkm.js:54043:19)
13:53:41.992 | at nodeImport (file:///opt/buildhome/repo/node_modules/vite/dist/node/chunks/dep-DkOS1hkm.js:55079:9)
13:53:41.992 | at async ssrImport (file:///opt/buildhome/repo/node_modules/vite/dist/node/chunks/dep-DkOS1hkm.js:54976:24)
13:53:41.992 | at async eval (/opt/buildhome/repo/node_modules/starlight-typedoc/libs/theme.ts:5:31)
13:53:41.992 | at async instantiateModule (file:///opt/buildhome/repo/node_modules/vite/dist/node/chunks/dep-DkOS1hkm.js:55036:9)
13:53:41.993 |
13:53:41.993 | 11:53:41 AM [vite] Error when evaluating SSR module /@fs/opt/buildhome/repo/node_modules/starlight-typedoc/index.ts: failed to import "/@fs/opt/buildhome/repo/node_modules/starlight-typedoc/libs/typedoc.ts"
13:53:41.993 | \|- SyntaxError: [vite] Named export 'MarkdownThemeRenderContext' not found. The requested module 'typedoc-plugin-markdown' is a CommonJS module, which may not support all module.exports as named exports.
13:53:41.993 | CommonJS modules can always be imported via the default export, for example using:
13:53:41.993 |
13:53:41.993 | import pkg from 'typedoc-plugin-markdown';
13:53:41.993 | const {MarkdownThemeRenderContext} = pkg;
13:53:41.993 |
13:53:41.993 | at analyzeImportedModDifference (file:///opt/buildhome/repo/node_modules/vite/dist/node/chunks/dep-DkOS1hkm.js:54043:19)
13:53:41.993 | at nodeImport (file:///opt/buildhome/repo/node_modules/vite/dist/node/chunks/dep-DkOS1hkm.js:55079:9)
13:53:41.994 | at async ssrImport (file:///opt/buildhome/repo/node_modules/vite/dist/node/chunks/dep-DkOS1hkm.js:54976:24)
13:53:41.994 | at async eval (/opt/buildhome/repo/node_modules/starlight-typedoc/libs/theme.ts:5:31)
13:53:41.994 | at async instantiateModule (file:///opt/buildhome/repo/node_modules/vite/dist/node/chunks/dep-DkOS1hkm.js:55036:9)
13:53:41.994 |
13:53:41.994 | 11:53:41 AM [vite] Error when evaluating SSR module /opt/buildhome/repo/documentation/astro.config.mts: failed to import "/@fs/opt/buildhome/repo/node_modules/starlight-typedoc/index.ts"
13:53:41.994 | \|- SyntaxError: [vite] Named export 'MarkdownThemeRenderContext' not found. The requested module 'typedoc-plugin-markdown' is a CommonJS module, which may not support all module.exports as named exports.
13:53:41.994 | CommonJS modules can always be imported via the default export, for example using:
13:53:41.994 |
13:53:41.994 | import pkg from 'typedoc-plugin-markdown';
13:53:41.994 | const {MarkdownThemeRenderContext} = pkg;
13:53:41.995 |
13:53:41.995 | at analyzeImportedModDifference (file:///opt/buildhome/repo/node_modules/vite/dist/node/chunks/dep-DkOS1hkm.js:54043:19)
13:53:41.995 | at nodeImport (file:///opt/buildhome/repo/node_modules/vite/dist/node/chunks/dep-DkOS1hkm.js:55079:9)
13:53:41.995 | at async ssrImport (file:///opt/buildhome/repo/node_modules/vite/dist/node/chunks/dep-DkOS1hkm.js:54976:24)
13:53:41.995 | at async eval (/opt/buildhome/repo/node_modules/starlight-typedoc/libs/theme.ts:5:31)
13:53:41.995 | at async instantiateModule (file:///opt/buildhome/repo/node_modules/vite/dist/node/chunks/dep-DkOS1hkm.js:55036:9)
13:53:41.995 |
13:53:41.995 | [astro] Unable to load your Astro config
13:53:41.996 |
13:53:42.458 | [vite] Named export 'MarkdownThemeRenderContext' not found. The requested module 'typedoc-plugin-markdown' is a CommonJS module, which may not support all module.exports as named exports.
13:53:42.458 | CommonJS modules can always be imported via the default export, for example using:
13:53:42.458 |
13:53:42.459 | import pkg from 'typedoc-plugin-markdown';
13:53:42.459 | const {MarkdownThemeRenderContext} = pkg;
13:53:42.459 |
13:53:42.459 | Stack trace:
13:53:42.459 | at analyzeImportedModDifference (file:///opt/buildhome/repo/node_modules/vite/dist/node/chunks/dep-DkOS1hkm.js:54043:19)
13:53:42.459 | at async ssrImport (file:///opt/buildhome/repo/node_modules/vite/dist/node/chunks/dep-DkOS1hkm.js:54976:24)
13:53:42.459 | at async instantiateModule (file:///opt/buildhome/repo/node_modules/vite/dist/node/chunks/dep-DkOS1hkm.js:55036:9)
13:53:42.607 | Failed: Error while executing user command. Exited with error code: 1
13:53:42.618 | Failed: build command exited with code: 1
13:53:43.468 | Failed: error occurred while running build command
</pre><!--EndFragment-->
</body>
</html>
yarn install --immutable in the root of the projectcd documentation/yarn buildThe code builds normally, without errors.
Every time
No response
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.