v1.0.0 goals and considerations

[that-hatter]

v1.0.0 will mark the version where every doc entry should have been manually looked over and consequently edited. The following are softer goals that may be decided or implemented along the way (they can be added in minor/patch bumps, not necessarily exactly on v1.0.0).

• "Guided" types #10
• Shorthand for internal links #11
• Consider adding a metatable field to types #12
• Figure out how to sort entries/how the order should be represented in the repo (if at all) #13
• API Versioning #14
• Non-function/constant namespace members #15

Finished Tasks

• Add Github Actions for checking commits. If it's a doc edit, run the parser to validate it and output errors in the Action log.

• Consider moving the typescript loader package to a different repo, making this only for the yaml files.

• Figure out when exactly to run steps. Right now, the yaml files are part of the release build and are parsed/validated every time they're needed. Files from the ygocore and CardScripts repo are also fetched every time to add the source code links.
  These steps, especially the former, could be done before release by building a validated.json file and having the loader script use that if it exists. The npm run dump script partly does this already, but the dump file is mainly for quick local checking and not part of the release artifact.

• Related to the previous two points, decide if the yaml files should be part of the semantic versioning. It would make sense for them to be if we decide to implement the validated.json file previously discussed.

• Consider adding a toUnsafe/toNonStrict function that converts the output API object to a format that plays nicely without using fp-ts and the markdown module (e.g. everything is mutable, Option<T> is converted to T | null, markdown values are just plain strings).
  This is a very low priority goal, since I don't expect the typescript package to be used outside scrapi projects.

[DyXel]

• Its probably a good idea to have a repository just with the YAMLs; Kind of like how we have the script checker on its own repository as documentation will probably need to be a live anyways (since most ecosystem is rolling-release)
• The generator/validator could be on its own repository, where semantic versioning is performed, and the YAML repository would pin a specific version to run on its CI for every commit/merged PR. (This is exactly how ScriptChecker and CardScripts repositories are set up currently)

[that-hatter]

Decided to separate the typescript loader to a separate repo.
This repo will contain only the yaml files and the specs, and can be moved to the ProjectIgnis org.
The subprojects that use the yaml files (wiki generator, discord bot, autocomplete file generator) don't need to be moved to the org.

Since the yamls will be treated as live documents, they will not be semver'd.
Instead, we can semver the spec, and the loader should check the version before running to make sure the constraints it expects to validate are synced.