[do not merge] Typedoc->Gitbook Implementation for Typescript

[dskvr]

Sample typedoc/gitbook implementation for an EOS typescript repository.

Typescript implementations are a bit more difficult due to lack of support for static files (tutorials, guides, explainer docs, etc). Solution would appear to be copying the files and then prepending the SUMMARY.md file dynamically based on files in docs/static, some ugly psuedocode

filesInStatic.each
  str += "[{{url.replace('-', ' ') }}]({{url}})"
Summary.prepend str

The above is not presently implemented due to a desire to maintain a separation of concerns between the repository and the documentation generation itself. There's some obvious solutions to this, from unideal and easy to ideal and difficult.

1. [unideal] Bash script in docs directory to handle copying and prepending generated SUMMARY.md. This is unideal because there's non-eosjs2 logic that needs to be maintained in the directory. Having the bash script executed in-line as an npm script has similar drawbacks
2. [acceptable] Write a typedoc plugin to make typedoc do what we want to do or modify typedoc-plugin-markdown (likely easier) There's a possibility this isn't possible with the Typedoc API and it creates maintenance overhead
3. [ideal] Create a standalone cli utility that generates documentation for any EOS repository for supported languages, removing any implementation requirements from the repository. This is probably the ideal route because then absolutely no documentation logic needs to exist in the repository outside of an optional configuration file. The tool simply takes arguments or reads a config file, parses files based on config and then places documentation into a directory

TODO:

• Skin [This is a todo for all these implementations]

[jeffreyssmith2nd]

45

[dskvr]

Most pieces are in place, next I need to modularize some components used in here so they are reusable.

[brandonfancher]

@dskvr This is looking great. I ran the build-serve-docs script, and the resulting documentation looks very nice.

After this is settled and merged, we can follow up with improvements to the documentation, itself. For example, in the API documentation, it's listing all of the API constructor params in a single block of text. We can improve this by moving those out into an ApiArgs interface. Will generate much nicer documentation.

Anyway, I'm in favor of proceeding with this approach after a fixup/squash of the commits herein. Nice work!

[dskvr]

Closing in favor of #69