Automated README.md generator & individual item files

[CamKem]

Allows you to automatically build the README.md file from files committed, PR's must add name.md into the respective subfolder of items, then the README.md will be automatically built on merge. There is an example.md in items folder, which is referenced in the updated contribution guide.

The automated build works using a GitHub Action workflow, to run npm run build-readme i added to package.json, which runs a cjs script I wrote to read the items files and build up the README.md. If you prefer not to use an action, you could pull the merged items locally, build the README.md using the command & push the changes. The build script takes into account order property in yaml or defaults to alphabetical listing, make your life easier.

The changes to the way the markdown files are as follows:

• sections & categories are defined in a sections.md in the partials directory (used for validation in building README.md)
• Partials, is also where header.md & contribution.md that are appended & prepended onto the README are stored.
• Items that are added to the readme are stored in /items then a subfolder for the section to organise the files

I have also added additional meta data properties to the yaml of the items, which could be useful for sorting, or additional rendering in the future, to provide more rich content. Mostly are empty properties for now, but could easily be filled as the project grows.

All the meta data for building the README.md is all stored in yaml front matter of each item, this means the .md files for the item could also have a long description or a full page content that could be rendered stored as markdown after the yaml. This could include moving the the interviews & guide markdown content into their item files & adjust where you look for it to render the content , would remove the need for the prefix currently used on the interview files, as the order is stored in the yaml meta data.

Let me know what you think, if you want any further details happy to provide it.

[CamKem]

This is how im keeping it in sync, just copy the markdown from README.md when you merge a new PR. Paste it into a locally, then run npm run parse-items & npm run build-readme & push the built files. Takes no time at all, mostly automated to keep in sync with new item. (haven't pushed the parse-items command, added-items.md, or the parse-added-items.cjs, as I probably only need them locally)

[CamKem]

Hey @timb-103 , I was hoping you would have had a chance to review this PR. Merging this would allow you to move forward with a more itemised control system & better version control, as each PR would only be touching the file they are adding or updating, not the central README.MD which is automatically built after each merge ensuring that each item passes validation for accuracy with the sections.md file in the build script, to ensure there is no broken link. The front-matter in each item will also give you more flexibility to add more advanced connectivity with your UI changes & improve UX having additional meta data by which to improve on SEO, making the site more extensible, as you can utilise the ability to add the content below the meta data to create popups, modals, tooltips, actual pages, whatever...

I have made sure the upstream commits have been moved into the history of this PR to address any of the merge conflicts that were happening in the README.md, hopefully that helps.

I'm happy to assist you and contact each existing PR author individually and get them to push changes to their PR so that it fall inline with the new structure.

It's all visible in the files changed script, but here is a few screen shots anyway.

Then here is a screenshot of how the updated contribution guidelines look locally & the example.md that I have put up in the items directory to follow.

[CamKem]

The branch is now up to date & there is no merge conflicts, I merged the upstream commits & everything is synced. As I had already done the PR a week earlier I have not squashed the commits, suggest that you should handle by doing a squash merge (or rebase merge) of the PR, if you want to bring over the changes.

[CamKem]

@timb-103 -- I went through and added review comments to explain the changes in further details, I hope it helps.