zk
e363bd2532
* docs: migrate from mkdocs to mdbook - Rename old mkdocs docs/ to old-docs/ for reference - Set up new docs/ with mdbook (book.toml + src/ tree) - Mirror full nav structure from mkdocs.yml into SUMMARY.md - Add Justfile-docs with docs-serve, docs-build, docs-check, docs-install recipes - Import Justfile-docs from root Justfile - Rewrite .github/workflows/docs.yml: build step uses taiki-e/install-action to install mdbook, split into separate build + deploy jobs, PR builds run the check step too * ci(docs): pin actions to SHAs, install mdbook via release binary * ci(docs): install mdbook from apt instead of curling a release binary * dev: replace mkdocs python stack with mdbook in dev image * ci(docs): apt only works on Debian; restore release binary install for Ubuntu CI * docs: fix duplicate file entries in SUMMARY.md * docs: remove docs-install recipe * docs: remove site-url from book.toml to fix asset loading * dev: install mdbook from upstream release binary, not Debian apt The Debian package (0.4.x+ds) strips bundled font assets, leaving the built site without fonts/fonts.css. Use the upstream tarball (same as CI) so the theme is complete. Handles x86_64 and aarch64. * docs: vendor mdbook tarballs in dev/mdbook/, install from there Dockerfile.dev uses COPY + tar to install the right arch at build time. CI extracts the x86_64 tarball directly from the checkout. No network access required for either — and no stripped-fonts Debian package. * fix: unwritten
1.3 KiB
Parsing Import Processing Info
The ImportProcessingInfo array returned from our importing process is unwieldy to work with. We are interested in what it has to say, though.
This step converts that array into data we use in successive score import steps.
!!! info
Because the logic for this is essentially just one
loop, it does not get its own file in score-importing/.
Instead, it is defined inside `score-import-main.ts`.
Output
| Property | Type | Description |
| :: | :: | :: |
| scoreIDs | Array<string> | The array of scoreIDs imported as a result of this import. |
| errors | Array<{ type, message }> | An array of the failed ImportProcessingInfo's Types and Error Messages.
| chartIDs | Set<string> | A set of the chartIDs modified by this import. This is a set to ensure that every chartID here is unique. |
| scorePlaytypeMap | Record<Playtype, Array<Score>> | All of the score documents returned filtered into Playtype buckets.
What's with ScorePlaytypeMap?
Some imports may import scores from multiple Playtypes. We frequently want to only refer to the set of scores modified under a given playtype (For importing a users game:playtype stats, as an example) so this is a very useful data structure to have.