🐛 BUG: Whitespace preserved after style is moved

[altano]

What version of @astrojs/compiler are you using?

2.11.0

What package manager are you using?

pnpm

What operating system are you using?

Mac

Describe the Bug

Back in 2022 @virchau13 demonstrated why preserving whitespace at the end of a component file (#406) was a bad idea and @natemoo-re fixed it as a bug.

A problem arises when a component defines both some html AND a style. The <style> tag is moved from the output but the whitespace at the end of the component file is preserved. So currently the order of operations is:

1. remove whitespace from end of component
2. move style tag from output, preserving space that existed between html and style tag, even if that now appears at the end of the component

This leads to surprising behavior, mainly because:

1. Whether the style appears above or below the html affects the trailing whitespace, even if in both cases there IS whitespace after the component.
2. the style isn't present in the output (not after the html), but affects the trimming of the html's trailing whitespace.

It might make sense to preserve the whitespace if the style tag were inlined, or if we always preserved the whitespace at the end of a component, but I don't think it makes sense to only preserve trailing whitespace if it appears before something we removed from the output.

I would suggest the order be reversed:

1. if something (like a style tag) is going to be removed from the output (or moved elsewhere), that should be in a first step
2. Then, if the component file has trailing whitespace, it should be removed.

Link to Minimal Reproducible Example

https://stackblitz.com/edit/withastro-astro-cra348t8?file=src%2Fpages%2Findex.astro

[natemoo-re]

Thanks for the ping! I haven't been actively maintaining the Astro compiler because it's no longer my day job, but in my opinion this does make sense to treat as a bug.

Unfortunately, there are undoubtedly many cases where this has created "load-bearing" whitespace bugs. I'm not positive what the path forward to fixing this is, but maybe we could introduce an experimental flag in Astro v5 and make the breaking fix as part of Astro v6.