Manually maintaining the table of contents is a chore. When a new question is added, the table of contents has to be manually updated with number, title and slug. If the title changes, the TOC has to be updated again. This can easily go out of sync.
Implementation
I added a script to generate the table of contents based on the questions. As much as possible, the script leaves the contents alone. The script works as follows:
It clears out the table of contents (between the TOC_START and TOC_END markers)
Process the list of questions (between the QUESTIONS_START and QUESTIONS_END markers) and collect the list of questions
While doing this, if there are incorrect/non-sequential numbers, the script will rename it for you.
Generate the table of contents markdown using the list of processed questions. The slugs are generated using github-slugger, it should be mostly the same as how GitHub slugify the titles.
Combined the sections back into a single file and write to disk.
The script can be executed by running npm run gen.
Results
Through using the generation script, it has found some misnumbered qns (e.g. 445 should be 443). You can check the result on the branch of my fork here, so far seems fine.
Motivation
Manually maintaining the table of contents is a chore. When a new question is added, the table of contents has to be manually updated with number, title and slug. If the title changes, the TOC has to be updated again. This can easily go out of sync.
Implementation
I added a script to generate the table of contents based on the questions. As much as possible, the script leaves the contents alone. The script works as follows:
TOC_START
andTOC_END
markers)QUESTIONS_START
andQUESTIONS_END
markers) and collect the list of questionsgithub-slugger
, it should be mostly the same as how GitHub slugify the titles.The script can be executed by running
npm run gen
.Results
Through using the generation script, it has found some misnumbered qns (e.g. 445 should be 443). You can check the result on the branch of my fork here, so far seems fine.