Group each version per release in the version bar

[ErrorCraft]

Groups and collapses the version bar by each release for the articles. They only go down a single level because people don't like going down too many levels (better UX), because Mojang's drop system usually increments the same version number as the one they increment for hotfixes (e.g. 1.21.9 and 1.21.10) and because that is what is classified as a stable version.

[vercel]

@ErrorCraft is attempting to deploy a commit to the vdvman1's projects Team on Vercel.

A member of the Team first needs to authorize it.

[vdvman1]

I've left a few comments for various bits of TS/JS/React cleanup. I feel like most of these should have been picked up by the linting tools, so I'm surprised they were left in. Please check that you have linting enabled in your editor to avoid these in future.

For the collapsing stuff, I'd suggest checking out how the TOC is implemented in the changelog articles, using a summary lets you avoid needing the hackery of an invisible checkbox, and will probably let you avoid needing the grid areas stuff.

It's probably worth splitting that collapsible stuff into a new component so it can be reused in both places. Shadcn/ui does include a collapsible component, but I don't think we should use it here since the content isn't visible to search engines if it starts out collapsed

[ErrorCraft]

I didn't have ESLint installed in VSCode so it didn't pick up or modify anything, but now it does. In fact, it automatically fixed some of the suggestions already! I think it would be useful to include that in the (future) contributing document too and to check for the linting in an action when you open a PR, because then I would have noticed it a lot earlier.

[ErrorCraft]

I will also migrate the version bar to other elements asap

[vdvman1]

I didn't have ESLint installed in VSCode so it didn't pick up or modify anything, but now it does. In fact, it automatically fixed some of the suggestions already! I think it would be useful to include that in the (future) contributing document too and to check for the linting in an action when you open a PR, because then I would have noticed it a lot earlier.

Yeah we definitely need a proper CONTRIBUTING.md document.
When it comes to running the linter in an action, in theory it would have run the linter in vercel if I had selected to deploy a preview, but it probably wouldn't hurt to have a separate action that runs even without the deployment.

[ErrorCraft]

When I use a summary element the browser complains that an interactive element (specifically an anchor element) is present inside the summary element which will hurt accessibility, so I'm not sure if I should use it for the version bar... (The same goes for the table of contents as they also contain anchor elements.)
This is the message:

An interactive element was found within a <summary> element. These elements will not consistently be accessible to people navigating by keyboard or using assistive technology.

[vdvman1]

Hmm, I wonder what the proper way to do this is then? Gonna need to do some research

[vdvman1]

I think we should just use the shadcn/ui collapsible component and accept the SEO hit. I think it's technically possible to force it to mount even while collapsed, but it involves some hacky tricks to get aria stuff working properly in that case, so I think we shouldn't bother with that just yet.

In future, if we want SEO we can add a dedicated page just for the list of versions with the links to the changelogs for those versions (potentially showing other pieces of information and links too). For now I think it isn't too important.

[vdvman1]

Might be able to use a sitemap to solve the SEO issues, so I'm considering just merging this as it is. I'm not fond of having a separate CSS file and non-tailwind classes, but that can be fixed in a separate PR that also fixes the TOC in the articles

[ErrorCraft]

Alright, then I'll just place the remaining props on multiple lines with trailing commas.