Optimise content parsing watch

[Dave Stewart]

Background

When Nuxt Content starts, it scans, parses and caches all content, so documents are processed only once.

Nuxt Content Assets hooks into the "after parse" hook and transforms asset paths, just before the content is cached.

Nuxt Content only updates the cache when documents are:

• edited: the document is re-parsed and re-cached
• moved or deleted: the content index is updated along with the cached result

However, because Nuxt Content skips cached content on some startups, Content Assets cannot be sure that all documents have had their relative image paths transformed.

Content Asset's rather brutal solution to solve the initial parse is to nuke the .nuxt/content-cache folder on each new build, which forces Content to re-parse and re-cache all content documents.

Whilst this is fine for smaller sites, it's possible that on larger sites and on Docus sites (see this bug) the lack of cache could be problematic (but to what degree I don't have data on)

Proposal

Rather than nuking the cache each time, the hook callback could be extracted to a standalone file, and applied to the cached files individually:

• the same algorithm could be used verbatim, passing the AST and checking for relative paths
  • already-converted absolute paths would be ignored
  • potentially a flag could be added to indicate a successful parse
• the content index would not need to be updated, as only the content, not the location changed
• the live-reload may need to be triggered

Live reload

Currently, not sure how to live-reload docs:

• could this be sent using another socket server, or does the existing one prevent a new one being created?
• if we can't do this, is there another way to trigger a reload?
• perhaps using the Content Assets websocket and refreshNuxtData()?
• perhaps just re-saving the content and letting Nuxt Content do its thing?

Notes

Aside from "doing the right thing" I don't know how much of a real world effect not nuking the cache will have.

Obviously, once the cache is deleted, updating image paths is fairly critical, but to what extent?

It should at least make Content startup quicker, as it will use the previously-cached values.

Before starting this work, we should research:

• how and when cached images are ignored during startup
• startup times for nuking vs not nuking he cache
• how changing image size but not updating the cache is an issue
• if changing an image already reloads the content
• how to reload arbitrary content if not
• etc