feat(v2): Docusaurus-init template for cli, api

[fanny]

🚀 Feature

I want to propose a new feature for our docusaurus-init CLI, to generate a structure that depends documentation's type, in addition to our templates based on themes. So, for example, if I have a CLI docs, we could have:

+ getting started/
   installation
   ....
+ commands/
   command1.md
   .....
+ ....

In the case of APIs, we could have:

+ Getting Started
+ Api Reference/

Currently we have docusaurus-classic and docusaurus-bootstrap, and although, they work pretty well, I was thinking if we could include new types of templates. I think this could be a differential for docusaurus, but I also understand that maybe it's better develop this far away from docusaurus core. Looking for opinions.

Have you read the Contributing Guidelines on issues?

yes

Motivation

Looking into the docusaurus showcase, we can see that our "clients", can be divided in three types: CLIs, APIs, Component Libraries, and so on. If you go trough some websites you'll see that they usually follow our structure, they have a Getting Started section, API Reference and etc...
So, I thought that we could do our templates have more "meaning", they are currently just files with lorem ipsum text, that the clients can reuse the setup of docusaurus.config.js for a theme. So, inspired by Express Application Generator, I thought that we could use those templates to provide something like a structure recommendation to the projects.

Pitch

(Please explain why this feature should be implemented and how it would be used.)

The work to build those templates, is basically improve things like: sidebar and current content of markdown of our templates.
Using this feature, we can use better the docusaurus-init template, we can save time for our clients, because they don't need to spend a bunch of time thinking in a structure for their docs. We can also take advantage of this generator to promote some features that we have that are good for some types of docs, like: tabs, admonitions etc.
And, in a positive way, we could be a reference of structure for those types of documentation.

[slorber]

That seems a good idea to me to have better templates to cover various needs, or at least enhance the starter template we already by including more useful things.

Also wonder if having to many options won't increase the maintenance cost, as we may forget to update the templates. We'll likely also provide TS templates too, so wonder if we shouldn't just have a JS and a TS version, but more fully-featured to represent a real use-case?

We should also probably deploy those templates in deploy previews so that we know easily when things break and to help review the templates. Hope it won't increase too much Netlify build times though.

[fanny]

That seems a good idea to me to have better templates to cover various needs, or at least enhance the starter template we already by including more useful things.
This is my point.

Your idea related with TS and JS, sound more simple and maintanable. My idea is a way to make the templates more useful in fact. About the previews, the templates are the way that we test the changes in themes, so I think that if we have an e2e set of tests connected with our CI, should work, or as a preview for Netlify.

[slorber]

As we are going to assign this task to MLH fellows, I've made a new one with clearer instructions:
#4079