PaloAltoNetworks / PaloAltoNetworks/docusaurus-openapi-docs

Introduce incremental `gen-api-docs` command to support watch functionality

Open
#1,128 0 comments 4 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

enhancement
Dominant language
TypeScript
Stars
1.1k
Forks
315
Avg merge
7d 5h
Merged PRs (30d)
7

Description

Is your feature request related to a problem?

Currently, with the existing gen-api-docs and clean-api-docs commands at our disposal I am unable to provide a workable "watch" functionality to enable quick iterative development. Due to how these commands are designed, they do not regenerate updated MDX files after changes have been made to the source OpenAPI schema (this has already been described in https://github.com/PaloAltoNetworks/docusaurus-openapi-docs/issues/615).

So, to end up with up-to-date MDX files, we have to clean all files and regenerate them.

Our problem with this design choice is that our Docusaurus dev server seems to be stalling and going OOM after the watcher sees so many MDX files being removed and re-added by this plugin. Even adding a timeout to the watcher does not prevent this: webpackConfig.watchOptions.aggregateTimeout = 10000;. The server just hangs and ultimately crashes. This means that we have to restart the Docusaurus dev server, which means that every development iteration takes at least 30 seconds, depending on the size of your site.

As a workaround, we found that when we generate files to a temporary directory, and then use rsync -r -v --size-only to copy only the changed files from the temporary directory back to the intentional directory, this strain on Webpack does not occur and the builds are working fine. This solution however is impractical, as the info_path of the generated mdx files then contains references to our temporary build directory.

Describe the solution you'd like

I would like to ask to reconsider the idea that @shmichael proposed in https://github.com/PaloAltoNetworks/docusaurus-openapi-docs/issues/615, which is to build the full file tree & touch only the actually modified files, to reduce IO and improve watcher performance.

Additionally, to remove all deleted files, one could keep track of the generated file tree in a temporary cache file, and on the next build, remove all existing files that were not part of this tree.

I am willing to help contribute towards an implementation, however I am unsure how this fits alongside the existing workflow of the gen & clean commands. Maybe a gen-api-docs:watch command could be introduced?

This would enable a quick regeneration & development cycle.

Describe alternatives you've considered
  • Build using gen-api-docs to a temporary dir, and use rsync -r -v --size-only to copy only the changed files from the temporary directory back to the intentional directory
  • Use Nodemon to provide a watch function nodemon --delay 1000ms --watch <my-openapi-spec-folder> --ext 'yaml' --exec 'yarn api-docs:tmp-dir:clean && yarn gen-api-docs && yarn api-docs:tmp-dir:rsync'
  • Prevent stalling the Docusaurus dev server using webpackConfig.watchOptions.aggregateTimeout = 10000;
Additional context

Thanks in advance!

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by tracing the existing gen-api-docs and clean-api-docs commands and review the related issue #615. Define how incremental generation should preserve unchanged files, remove files absent from the generated tree, and fit with the existing gen and clean workflow. Done means source schema changes can regenerate only affected MDX files without the temporary-directory workaround or a full cleanup.

Written by the indexing model from the issue text.

Assessment

Tech stack
openapi, typescript
Domain
documentation, tooling
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.