CSS optimization workflow parity during development (inlining @import statements)

[thescientist13]

Summary

CSS supports referencing other CSS files using @import statements

/* theme.css */
@import "../../node_modules/prism-themes/themes/prism-nord.css";

During production builds, Greenwood will inline these statements as part of the CSS optimization phase, but why not also do this during development? Well...

Details

The principal use case here is that @import is not supported in Shadow DOM, so if you do, you will get an error like this in the browser

and thus unresolved @import paths

You can of course use our PostCSS plugin + postcss-import and this will happen in development and production, but as stated, this already something Greenwood does during production so why not at least "backport" some of this behavior during development, if at minimum to provide a consistent development vs production experience.

---

Misc observations coming out of ProjectEvergreen/www.greenwoodjs.dev#74

1. if we optimize when serving dev, then do we need shouldOptimize? - seems like no
2. should we make it optional since it is not standard behavior?
   • we were doing it for production... - make it optional and / or ignore certain operations in dev mode
3. Should we avoid any excess operations? (though really, once you turn it into an AST, the heavy lifting is really already there), like
   • minification - dev tools can format I think?
   • hashing - moderately expensive, but not really needed either way (use fs etc)
4. need to handle inline optimization bundle mapping edge case (see chore/upgrade greenwood v0.30.0 AnalogStudiosRI/www.analogstudios.net#98)
5. Seems staticServer is using shouldServe lifecycle, which at least explains unexpected prebundling, which we means we don't actually decouple plugins from server hosting... (relates a a need / idea around standalone server, which I should also track)
   • yeah npx http-server ./public breaks
   • npx http-server loads all the content just fine, nowstandard resource plugins needed. So do we even need resource plugins for staticStatic