Is it possible to pull siteConfig when extending the Docusaurus cli?

[Devon-White]

I'm working on a llms.txt plugin, and the plugin has the option to run during postBuild or to disable it and manually invoke it with a cli command: docusaurus llms-txt

Additionally, one of the options i have is to convert relative paths to full urls (if enabled) to match the stripe recommendations.

This said, is there a way to grab the context/siteConfig when invoking a docusaurus command?

So for what I've done is grab the context on postBuild and save the needed config items into a cache file in .docusaurus. If the option to skip the postBuild is enabled, after saving the config, the plugin will exit. Then when I run the cli, the cache file will be present to use.

[slorber]

This said, is there a way to grab the context/siteConfig when invoking a docusaurus command?

Yes, the plugin receives the site context as a parameter that you can use in any lifecycle method:

export default function (context, options) {
  return {
    name: 'docusaurus-plugin',
    extendCli(cli) {
      cli
        .command('llms-txt')
        .description('Generates a llms.txt file')
        .action(() => {
          console.log(context.siteConfig);
        });
    },
  };
}

---

We may be interested in having such a plugin in the core repo.

However, I'm not yet convinced of the usefulness of this weird file format that everybody produces, but not sure any crawler consumes it.

Related:

• New Docusaurus plugin: docusaurus-plugin-llms-txt #10899
• Add script for generating llms.txt react-native-website#4590

Regarding the implementation, I think it would be more reliable to use the postBuild() lifecycle. Like the sitemap plugin, we could iterate over the final routes to create the llms content. We now associate metadata with each route, such as the source file that generated it, which may be useful to link back to the original Markdown files.

It's not clear to me how such a plugin would decide to create markdown headings, how things get grouped and ordered in the final output. Relying on reading the file system and fancy heuristics, trying to reimplement the docs sidebar and other similar things is not going to be the most reliable, and it would probably be better if Docusaurus somehow associated page "breadcrumb" metadata to each route in the postBuild() lifecycle. However this would not be possible anymore to generate the file with a simple CLI call, and require a full build (or we can keep a cache like you did, but wonder if it won't be confusing for users)

[Devon-White]

This said, is there a way to grab the context/siteConfig when invoking a docusaurus command?

Yes, the plugin receives the site context as a parameter that you can use in any lifecycle method:

export default function (context, options) {
  return {
    name: 'docusaurus-plugin',
    extendCli(cli) {
      cli
        .command('llms-txt')
        .description('Generates a llms.txt file')
        .action(() => {
          console.log(context.siteConfig);
        });
    },
  };
}

We may be interested in having such a plugin in the core repo.

However, I'm not yet convinced of the usefulness of this weird file format that everybody produces, but not sure any crawler consumes it.

Related:

• New Docusaurus plugin: docusaurus-plugin-llms-txt #10899
• Add script for generating llms.txt react-native-website#4590

Regarding the implementation, I think it would be more reliable to use the postBuild() lifecycle. Like the sitemap plugin, we could iterate over the final routes to create the llms content. We now associate metadata with each route, such as the source file that generated it, which may be useful to link back to the original Markdown files.

It's not clear to me how such a plugin would decide to create markdown headings, how things get grouped and ordered in the final output. Relying on reading the file system and fancy heuristics, trying to reimplement the docs sidebar and other similar things is not going to be the most reliable, and it would probably be better if Docusaurus somehow associated page "breadcrumb" metadata to each route in the postBuild() lifecycle. However this would not be possible anymore to generate the file with a simple CLI call, and require a full build (or we can keep a cache like you did, but wonder if it won't be confusing for users)

Appreciate the response! Above suggestion worked great! :)

All great points/concerns for the plugin.

I would say the difference in my plugin compared to what im seeing from others is that not only am i creating a llms-txt file, i also include a pluginOption to convert the entire docs to a markdown version in the same path/route. So a route like /test/page will also have companion /test/page.md route. Then theres some rehype plugins i include to ensure proper markdown generation (handling list in tables, updating links to match our md links, etc,)

Rather then extract the content via sidebar file or during the contentLoaded lifecycle i opted for postBuild due to the fact that content will be fully rendered, which means we dont need to worry about weirdness like worring about MDX partials or components.

For creating the routes ,im reading the build directory via fs actions, and using some Docusaurus utils to ensure im getting the correct path, via safeGlobby and then converting the path with toPosixPath, with some error catching.

Do you suggest a different approach for this? I just pushed my first PR for the plugin which can be seen here: signalwire/docs#290

Its meant to be highly customizable/flexible, and have the ability to work with any page (if correct selectors are provided.).

One thing i have not solved yet is verifying the urls actually exist (will be added soon - i currently only verify the path exists.)

Any and all feedback (even brutal) is extremely welcome, as this is one of my first attempts at a bigger docusaurus project.