netlify-plugin-gatsby
netlify-plugin-gatsby copied to clipboard
Investigate reducing function .cache folder size by excluding media assets
From prioritization call: we could take a similar approach to the #320 where we offer a feature flag where customers can load their media assets via the .cache folder (default) or opt to not include/load them from the cache and instead opt to fetch them in requests
It worth investigating why this happens. The only reason they should be being moved into there is because if there's some kind of dependency that webpack has found. It might be worth seeing if we can work out if they really are needed. e.g. it might just be a case of them require()
ing them to get the path for embedding them
Is this related to the behaviour pointed out in this issue, where .cache/page-ssr/routes/static/*
is included in the function bundles?
I ran into the same issue before, and dealt with it by adding the following to my netlify.toml
:
[functions]
included_files = ["!.cache/page-ssr/routes/static/**"]
Many (if not all) of the static assets that were part of that folder were images and videos included in statically-generated blog pages in my site. None of them are require
d by any of my SSR pages, but they still end up in my function bundles if I don't manually ignore them using the config above.
I'd be really excited to see this exclusion of media assets happening automatically, if that's what y'all are planning to do! 😁
@orinokai - Was there an initial customer issue that raised this? Have we got any more information for reproduction? Thanks!
We will likely be doing work on gatsby
side of things to decrease size of generated engines. The one mentioned by @trevorblades was already handled in gatsby ( https://github.com/gatsbyjs/gatsby/pull/37284 ) and https://github.com/gatsbyjs/gatsby/issues/37713 has ideas for futher improvements. There is already flag for excluding DB from function tarball.
I do think this should be closed in favour of https://github.com/gatsbyjs/gatsby/issues/37713 to address problems at their source and not try to workaround them in the @netlify/plugin-gatsby
Thanks @pieh, yes that makes sense to tackle it at source. Closing this in favour of https://github.com/gatsbyjs/gatsby/issues/37713