Adding support for CSS modules

[jakearchibald]

I think this gets us a step closer to a decent CSS build system, but still feels some way off.

@argyleink @una is there a CSS build system you're particularly happy with, both in terms of developer ergonomics and performance? We never really got there with the devsummit site, so I'm interested to hear about prior art rather than totally reinventing something.

[github-actions]

🚀 Deploy preview for e670622:
https://tooling-report--698566fd0a9c2004.web.app
_{(Thu, 12 Mar 2020 15:40:30 GMT)}

_{firebase-preview-action}

[jakearchibald]

Had to drop the use of css: prefix 😢

If the import is css:./styles.css, there's no way to tell typescript to treat ./styles.css as a relative path. I'll file an issue with them.

[jakearchibald]

microsoft/TypeScript#37319

[jakearchibald]

I'm prefixing all these exports with $ for two reasons. It avoids clashes with JS reserved words, so .return becomes $return, and it means we can add other exports that won't clash.

Happy to change the prefix if there's a preference.

[surma]

We should prefix them with 🎨

[una]

Is that a real possibility? (Because I'm all for that) -- but aren't there emoji clashes in Linux?

[surma]

I think technically it should work, but we’re honestly just asking for trouble and it’s a ball-ache to type.

[argyleink]

reminds me of this from justin w3c/csswg-drafts#3714

[jakearchibald]

I moved all the CSS processing to buildStart so the css.d.ts files are generated before TypeScript gets there. It does mean that we might build CSS files that aren't referenced anywhere, but that should be rare.

[una]

I think this is a great step in the right direction! Thanks Jake 😄

Here's a branch with the change applied to the styled footer PR for exploration/ref https://github.com/GoogleChromeLabs/tooling.report/tree/styled-footer-css-modules (I'll update it once this is merged)

One thing to note is that this doesn't allow component-based style scope by default (i.e. we will still need to add a class to the parent to scope styles). We'll want to do this anyway to benefit from the code splitting this allows.

To summarize our chat, next steps will be to resolve what to do with component code so we don't have a bunch of floating code blocks per each component. Things to consider:

• persistent components (header/footer)
• views based on pages (summary cards)
• dynamic components (appear on the page after initial load with some user interaction -- do we have any of these?)

Initial thoughts are to inline critical CSS in the head, then have a global/persistent CSS file at the bottom of the document with all persistent components, then use inline styles injected into a unique file per-page. We can also do a style injection when X pixels above a component (i've seen this before but feels like the scroll listener will be heavier than the CSS savings). I'm not aware of any dynamic components in the design that won't be there on initial page load so I think page-level would suffice, but let me know if I'm wrong there.

cc @argyleink

[jakearchibald]

One thing to note is that this doesn't allow component-based style scope by default (i.e. we will still need to add a class to the parent to scope styles).

I thought it did that by renaming all the classes? Or is there some other mechanism?

We can also do a style injection when X pixels above a component (i've seen this before but feels like the scroll listener will be heavier than the CSS savings).

Yeah, I think that'll be too heavy. Also, those things tend to mess up links that point half way down the page.

I'm not aware of any dynamic components in the design that won't be there on initial page load so I think page-level would suffice, but let me know if I'm wrong there.

Oddly, I think dynamic CSS would be pretty easy, since we'd just inline it in the component JS and append it to the page on load. But yeah, I don't think we have any dynamic components planned.

[una]

I thought it did that by renaming all the classes? Or is there some other mechanism?

This does work when you add classes -- it doesn't scope without them (which is what I meant by "default"), i.e. styling a li within the footer component styles all li's on the page. When I've used CSS Modules in the past, everything is scoped to the component so there wouldn't be a conflict.

It's not a huge issue as long as we're aware

[jakearchibald]

CSS Modules in the past, everything is scoped to the component so there wouldn't be a conflict.

Ohh, do you know which implementation of CSS modules that was? I don't think Webpack does that.

[argyleink]

this is cool:

• free naming: clobberless dx
• free scoping: thx to free naming (on us to figure out how to stay dry)
• option to get raw styles from file, makes for straight forward manual splitting, we get to choose
• postcss: we still get nesting syntax and the option to bring in more if we want

minimal and unblocks us. seems like it doesnt stop us from making other choices 👍

i guess the only reason to not take it would be if we wanted to hand role an atomic stylesheet, like a hand rolled tailwind? the purist in me wants to do that, but the realist says we can succeed with both, and this work is good. aka the tradeoffs are splitting hairs, and we're fortunate to be stuck between 2 nice options.

jake, did i miss any of the css dx conveniences we have available in this PR? thx for the markdown additions too 👍

[jakearchibald]

@una

CSS Modules in the past, everything is scoped to the component so there wouldn't be a conflict.

Ohh, do you know which implementation of CSS modules that was? I don't think Webpack does that.

FWIW, Next.js's implementation will throw if you have a rule like ul li { background: green }. It complains that it isn't 'pure', since it doesn't contain a class name that can be made unique.

You can work around it using :global, but then you're explicitly opting out of scoping.

[jakearchibald]

@argyleink

jake, did i miss any of the css dx conveniences we have available in this PR?

Nope, that's pretty much it.