Changes

This PR refactors how we handle propagated styles and scripts in the Rollup generateBundle phase.

Context

A propagated module, e.g./Users/.../blog.mdx?astroPropagatedAsset, contains styles and scripts. The styles and scripts are only attached to the head if that blog.mdx is actually rendered, prevent other content styles and scripts from leaking.

Before


The data structure we used to track propagated modules to it styles and scripts is something like this:

Map {
 
  "/src/pages/index.astro" => Map {
    "/Users/.../blog1.mdx?astroPropagatedAsset" => { styles: Set {}, scripts: Set {} }
    "/Users/.../blog2.mdx?astroPropagatedAsset" => { styles: Set {}, scripts: Set {} } 
  },
  "/src/pages/other.astro" => Map {
    "/Users/.../blog1.mdx?astroPropagatedAsset" => { styles: Set {}, scripts: Set {} }
  }
}

This is great because we have information of which top-level pages uses what propagated modules and its styles and scripts. However, (correct me if I'm wrong) I noticed we're not using this information at all.

The only place we consume the information is here, but you can notice that both propagated styles searching and propagated scripts searching do the same logic, so in practice the work done in all places are kinda negated.

After

This PR simplifies and flattens it to:

// internals.propagatedStylesMap
Map {
    "/Users/.../blog1.mdx?astroPropagatedAsset" => Set {}
    "/Users/.../blog2.mdx?astroPropagatedAsset" => Set {}
 }

// internals.propagatedScriptsMap
Map {
    "/Users/.../blog1.mdx?astroPropagatedAsset" => Set {}
    "/Users/.../blog2.mdx?astroPropagatedAsset" => Set {}
 }

This way there's only a single "propagated module to styles/scripts" map, each key deduplicated, and we can save the work to figure out which page uses what propagated module, which was very expensive.

This is actually the pattern that Content Collection Cache used, and seems like it's on the right track abstracting this. So this PR also unifies how it's handled with CCC.

Performance

The goal of this refactor is to reduce calls to getParentModuleInfos, before it took 7.5s, now it takes 0.05s. Seems like making the work O(n^2) to O(n) is quite significant.

Testing

Existing tests should pass. I think we have some comprehensive tests around this. I also clicked around the local docs build and all looks good as before.

Docs

Added a changeset because I'm a bit afraid this may break some edge cases.