feat: improve readme loading and error handling

[essenmitsosse]

For now a little experimental, what to do some exploration and see if this could be a direction we can/should be going.

1. Extract Readme component from package page
   This has the benefit of better separation of concerns. The data loading is also moved into the component. Since the Playground component needs the same data, both now do a fetch, but that gets deduplicated.
2. Add explicit loading and error state for Readme
   This mainly fixes the issue of "There is no Readme appearing" when something goes wrong

As it is currently implemented I am not sure in which cases the loading state for the Readme would appear. We could load it non-blocking which would render the rest of the page faster so it can load in the background. I am not sure exactly though what the best way to do this in Nuxt is.

I think ideally the whole page should be rendered via SSR, if all the fetches have cached results. Otherwise a component like the readme component could be client side rendered to have faster time to interaction.

This pattern would also allow us to control the loading skeletons on a per component basis, while making it easier to already show headings etc.

If we would follow through with this the whole page could be small components, each fetching their own data, with Nuxt deduplication making sure we fetch the same thing twice. I have worked with a similar pattern in Next and I really liked it from a DX as well as from a UX perspective (because it makes it easier to show each thing as early as possible, without being blocked by other data that might be needed elsewhere).

Open questions

• SWR. Currently you might see an outdated version of the readme, but it looks ready and then might change after a moment to the current version. Is that what we want? Shouldn't there at least be some indication that it's still refreshing?
• I think someone mentioned that caching happens only for explicit version, but most package views will come from non-explicit version, so they will always have to get the correct version first?
• There might also be some problem with the current setup and changes to be made, because I am not sure, if this way the Readme will start to fetch it's data before the main package page is ready.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
npmx.dev	Ready	Preview, Comment	Feb 11, 2026 0:19am

2 Skipped Deployments

Project	Deployment	Actions	Updated (UTC)
docs.npmx.dev	Ignored	Preview	Feb 11, 2026 0:19am
npmx-lunaria	Ignored		Feb 11, 2026 0:19am

[github-actions]

Lunaria Status Overview

🌕 This pull request will trigger status changes.

Learn more

By default, every PR changing files present in the Lunaria configuration's files property will be considered and trigger status changes accordingly.

You can change this by adding one of the keywords present in the ignoreKeywords property in your Lunaria configuration file in the PR's title (ignoring all files) or by including a tracker directive in the merged commit's description.

Tracked Files

File	Note
lunaria/files/en-GB.json	Localization changed, will be marked as complete.
lunaria/files/en-US.json	Source changed, localizations will be marked as outdated.

Warnings reference

Icon	Description
🔄️	The source for this localization has been updated since the creation of this pull request, make sure all changes in the source have been applied.

[essenmitsosse]

Alternative approach would be to still load all the data in the main page component, but pass the fetch response object (including status and error) to the components to handle those correctly. This wouldn't change much about the data fetching, but would still allow for more granular loading state and error handling. Would also allow to test the loading state per component.