Feature suggestion: CLI tool to rebuild old doc versions

[toebeann]

Summary

At present, after a while of using this plugin, it is possible to end up in a position where you have old docs built with entirely different styles, themes, plugins etc. to your latest docs build. This could make browsing older docs feel quite inconsistent. On top of that, as typedoc itself updates, it may change the way it renders certain things, and on later runs you might change your typedoc configs to be inconsistent with earlier doc builds. Presently, the only way to deal with this is to manually checkout your older version, update typedoc, install any plugins including themes, change the config, etc.

It would be very nice to be able to automate this process, and for this automation to be usable via GitHub workflows and package.json scripts. Therefore, a CLI tool fits the bill, and is relatively simple to achieve via the package.json bin field.

Details

• rely on git tags as semantic versions. check them out, and update typedoc/install plugins/update config as necessary
• optional argument to specify versions to rebuild docs for, ideally should be possible to specify ranges and use wildcards etc. By default should rebuild only the docs for versions that are currently built
• optional arguments to specify typedoc version, and plugins and their versions, config options, etc.
• ideally, it should also be possible to set arguments in typedoc config file. arguments passed at the CLI should take precedence

Suggested command name/aliases

• typedoc-plugin-versions rebuild
  • typedoc-plugin-versions r
  • tpversions rebuild
  • tpversions r
  • tpv rebuild
  • tpv r

For now will leave this unassigned, but I'm happy to work on this once my current draft PR #10 is completed, at which point I'll assign myself unless someone else wants to volunteer 🙂

[citkane]

I think that this, and #12, are both fine ideas, but will be better suited as a standalone project / plugin.

I say this because your proposed features are concerned with the CID environment, while the existing plugin's code has no influence on that. That is to say; the concerns are separate, the documentation is simple, the development experience is focused, and I would prefer to keep it that way.

I do not foresee that your proposed features will require significant (if any at all) changes to the existing plugin code, but that can always be facilitated in lock-step if needed (maybe by identifying and exposing a public API).

This plugin's documentation can link to the other project as an opinionated resource to set up and manage the CID environment, something like it already does here.