Very nice! A big improvement from the current docs.

Another idea that popped into my head was that hovering over something like this would also show what the strikethrough/whatever means, but that might be unnecessary since it probably also says that somewhere else below...

I would probably some different combination of dimming and striking through them, both in the table of contents and titles of the sections

Would it be a good idea to strikethrough legacy APIs instead of having a vague L badge next to them? Or maybe changing it from blue to yellow or orange?

Nushell's `explore` is also pretty nice. :)
`npm info --json vite | from json | explore`

It's the best, beats the rest

There's a difference between taking time adding more content in the vein of Silksong and spending massive amounts of money and time implementing realistic rocks and trees and a huge, open, empty world

If it wasn't for cjs still existing and going to be around I would say .js, but generally I believe in more explicitness being better so I always turn on specific extensions, and use .ts in source files

for even better performance, avoid importing typescript and babel packages at all :^)

And of course, I fully agree with you when talking about running the tests in the build output 😄

I personally don't see the issue with importing .ts extensions in .ts files that either support it or won't run because the runtime doesn't support TS files anyways

I get the idea why you would want to keep the extensions same in src and dist, but I would also argue that importing `foo.ts` with `./foo.js` makes less sense than rewriting extensions when compiling TS files to JS

I understood as much, I was just asking if there was any more reasons than testing the published files [...]

Surely we can create a better version of yaml that isn't surreal to learn about?
I'm sure no one has had this idea before!

Seriously though, a subset of yaml that lets parsers be small and fast shouldn't be too impossible, no?