Improve content collection styles and scripts build perf

[bluwy]

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.

[changeset-bot]

🦋 Changeset detected

Latest commit: 0cdf248

The changes in this PR will be included in the next version bump.

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[natemoo-re]

Oooh that's great, nice work identifying this! I wouldn't be surprised if there were a few other inefficient data structures lurking around this part of the codebase...

[bluwy]

Marked this for 4.8 as I'd like to merged this in a minor together (to be safe)

[sarah11918]

Looks great, @bluwy , and happy to have content collections improvements! Tiny tweak to the changeset mostly so I didn't have to do any grammar research. 😅 (And, collections plural). Otherwise, approved for docs! 🥳