Several chunk files are added to the SSR bundle for every prerendered mardkown files

[regisphilibert]

Astro Info

Astro                    v4.5.0
Node                     v21.1.0
System                   macOS (arm64)
Package Manager          npm
Output                   hybrid
Adapter                  @astrojs/netlify v5.1.3
Integrations             none

Describe the Bug

When publishing an Astro project with output set to hybrid, it appears the Netlify adapter will add to the ssr/functions-internal/ssr/chunks directory several files for every markdown files present in the content directory.

It seems only invoking the getCollections method on one collection suffice for all the "content" files to be added to the bundle.

For one advancing-la-crosse.md following files are generated: (I suppose the bigger the content, the more chunks)

• .netlify/functions-internal/ssr/chunks/advancing-la-crosse_HTeAmckn.mjs
• .netlify/functions-internal/ssr/chunks/advancing-la-crosse_WrVGU8CN.mjs
• .netlify/functions-internal/ssr/chunks/advancing-la-crosse_YBMYQhAr.mjs

This happens even though the project only sports one SSR route with no relations to the markdown files.

I'm afraid this could quickly bloat the bundle on big projects and potentially generate the dreaded following error which I'm currently experiencing on some projects. It breaks the build during the deploy state:

Deploy did not succeed with HTTP Error 400: [PUT /deploys/{deploy_id}/functions/{name}][400] uploadDeployFunction default  &{Code:400 Message:Failed to create function on AWS Lambda: invalid parameter for lambda creation: Unzipped size must be smaller than 262144000 bytes}

What's the expected result?

The bundle should only add the chunks needed for the SSR routes to be functionnal.

Link to Minimal Reproducible Example

https://github.com/regisphilibert/astro-issue-repro-ssl-bundle-collections

Participation

• I am willing to submit a pull request for this issue.

[alexanderniebuhr]

cc @Skn0tt

[Skn0tt]

I can also see these files being generated, but I'm not aware of anything specific to the Netlify adapter that would cause it. I'm seeing the same behaviour with @astrojs/node adapter, so it looks like this stems from Astro core.

While those files are generated, I don't see them referenced from any other generated file. This also means that Netlify's bundling mechanism won't include them in the Lambda, so they shouldn't lead to any upload failures because of bundle size.

@alexanderniebuhr should we move this ticket into Astro core for investigation?

[ematipico]

Trying to understand if the issue belongs to content collections or astro code, still, this is concerning.

[alexanderniebuhr]

I think we do face the same issue in Cloudflare v10 now. Maybe it helps debugging (withastro/adapters#218)

[salloom-domani]

@alexanderniebuhr In my case I have a file with 21.8 MB that have index name prefix inside the pages folder

[4.0K]  dist/_worker.js/chunks/pages
├── [ 44K]  generic_CYGdUPp9.mjs
├── [ 21M]  index_B5vzoNaZ.mjs
└── [1.6K]  subscribe_Mgs9DD5k.mjs

EDIT: my bad the issue was that I used lots of astro-icon packs and forgot to limit them in prod, hope somebody will benefit of this

[matthewp]

I don't think this is actually a bug. It's a side-effect of the fact that content collections compile to JavaScript. We are not able to "tree shake" unused collections because those APIs are completely dynamic.

We are investigating having CC be backed by a database as an alternative to the JS structure. That may or may not help with this type of issue.

[alexanderniebuhr]

@matthewp I agree with you. I think the initial issue was, that all the "pages" even if prerendered ended up in the output, due to the prerendering chunk issue. But since we do have a solution for that incoming, I'm not sure if that is still an issue here, or if that this issue is also resolved by that 🤔

[bluwy]

I initially thought that #11245 would fix this, but it doesn't as content collection adds all collection entries as Rollup entries:

astro/packages/astro/src/core/build/plugins/plugin-content.ts

Lines 135 to 146 in 7d59750

	// Of the cached entries, these ones need to be rebuilt
	for (const { type, entry } of entries.buildFromSource) {
	const fileURL = encodeURI(joinPaths(opts.settings.config.root.toString(), entry));
	const input = fileURLToPath(fileURL);
	// Adds `/src/content/blog/post-1.md?astroContentCollectionEntry` as a top-level input
	const inputs = [`${input}?${collectionTypeToFlag(type)}`];
	if (type === 'content') {
	// Content entries also need to include the version with the RENDER flag
	inputs.push(`${input}?${CONTENT_RENDER_FLAG}`);
	}
	newOptions = addRollupInput(newOptions, inputs);
	}

Which makes the prerender plugin think that they have other uses, and doesn't mark them for deletion. It's possible to improve this interaction, perhaps easiest if content collection put each in their own non-entry chunk (with manualChunk).

Other than that, what Matthew mention is still true though as long as one non-prerendered pages uses getCollection.

[matthewp]

Ok, going to close as I don't think there's anything we can fix about this.