{"id":126,"date":"2023-12-06T16:30:46","date_gmt":"2023-12-06T16:30:46","guid":{"rendered":"http:\/\/fem.flywheelsites.com\/?p=126"},"modified":"2024-02-20T21:35:21","modified_gmt":"2024-02-21T03:35:21","slug":"fine-ill-use-a-super-basic-css-processing-setup","status":"publish","type":"post","link":"https:\/\/frontendmasters.com\/blog\/fine-ill-use-a-super-basic-css-processing-setup\/","title":{"rendered":"Fine, I’ll Use a Super Basic CSS Processing Setup."},"content":{"rendered":"\n

If you’d like, you can jump straight to the setup<\/a>, but I’d like to lay down my thinking first. Here goes. <\/strong><\/p>\n\n\n\n

\n\n\n\n

These days I try<\/em> to use just CSS. You don’t need a CSS processor these days like you used to, thanks to native CSS getting so much<\/em> better over the years. <\/p>\n\n\n\n

I used to reach for Sass<\/a> like seconds on Thanksgiving. Of course<\/em> I’m going for it. There was so much value there! Nesting, loops, mixins, includes, variables, math, just a cornucopia of value. Most of that stuff is in CSS now, and better.<\/em><\/p>\n\n\n\n

Except includes. Dammit<\/em>.<\/p>\n\n\n\n

Good ones, anyway. Native CSS has @import<\/code> which is technically an include. I suppose it predates ESM imports by gotta be somewhere near 2 decades. But all it does is trigger another HTTP Request for another stylesheet. It doesn’t concatenate them together which is generally what you want with CSS. Bundle<\/em>, as it were.<\/p>\n\n\n\n

So Sass made @import<\/code> do bundling. That was a weird call, actually, since it trampled over a native CSS feature in a way that Sass was usually very good about not<\/em> doing. <\/p>\n\n\n\n

And I’d usually lump on PostCSS<\/a> too, mostly because Autoprefixer<\/a> had a real hay day of usefulness. These days, there is only precious few things left that even need it anymore (looking at you, mask<\/code>). <\/p>\n\n\n\n

So, between Sass and PostCSS (and probably a specialized minifier), that was getting to be a rather complex CSS processing pipeline. Plus, you’d always have to figure out how to wire it up with whatever other site-building dance you were doing. Maybe you had your own favorites. I know there are Less and Stylus people out there, not to mention a soup of potential PostCSS plugins, specialty tools like CSS modules, and the rest of the iceberg of CSS-in-JS machines. <\/p>\n\n\n\n

That fatigued me, and so again: these days I try<\/em> to use just CSS.<\/p>\n\n\n\n

But there are still growing pains as a single CSS file gets bigger. The length of the file can get annoying. The odd CSS property or value that still needs prefixing. The desire to use some new CSS feature that would be easier with a sprinkle of processing.<\/p>\n\n\n\n

SO FINE:<\/p>\n\n\n\n

Let’s wire up a modern CSS processing setup.<\/h2>\n\n\n
\n
\"\"<\/figure>\n<\/div>\n\n\n

We’re going to use Lightning CSS<\/a>. It has one job: processing CSS. But offers a compelling set of features:<\/p>\n\n\n\n

    \n
  1. Bundling<\/li>\n\n\n\n
  2. Syntax Lowering<\/li>\n\n\n\n
  3. Vendor prefixing<\/li>\n\n\n\n
  4. Minification<\/li>\n<\/ol>\n\n\n\n

    I’ll get to the details of those as we go. <\/p>\n\n\n\n

    First, let’s get it installed. Here’s both the core and the CLI because that’s where we want to use it:<\/p>\n\n\n

    npm install lightningcss lightningcss-cli --save-dev<\/code><\/span>Code language:<\/span> Bash<\/span> (<\/span>bash<\/span>)<\/span><\/small><\/pre>\n\n\n
    Lightning CSS is from the Parcel project, but here we’re not using it via Parcel, we’re using it directly. It’s now ready to be called at the command line.<\/p>\n\n\n\n
    Say we have a style.css<\/code> file and we’re going to process it into a style-min.css<\/code> file:<\/p>\n\n\n
    lightningcss --bundle --targets '>= 0.25%'<\/span> --minifystyle.css -o style-min.css<\/code><\/span>Code language:<\/span> Bash<\/span> (<\/span>bash<\/span>)<\/span><\/small><\/pre>\n\n\n
    Sweet, done. <\/p>\n\n\n\n
    Notice we’re specifically asking for the features we want via flags.<\/p>\n\n\n\n
    We’re going to want a file watcher.<\/h3>\n\n\n\n
    \"\"\/<\/figure>\n\n\n\n
    We could make this script easier to run by putting it in our package.json<\/code> like:<\/p>\n\n\n
      \"scripts\"<\/span>: {\n    \"process\"<\/span>: \"lightningcss --bundle --targets '>= 0.25%' --minifystyle.css -o style-min.css\"<\/span>\n  },<\/code><\/span>Code language:<\/span> JSON \/ JSON with Comments<\/span> (<\/span>json<\/span>)<\/span><\/small><\/pre>\n\n\n
    But that’s no fun. <\/p>\n\n\n\n
    Now every time we write some CSS we have to come back to the command line, run npm run process<\/code> and then head over to the browser and refresh it to see the changes? We’ve made the choice opt-in to some extra technology here, so let’s get the DX right. <\/p>\n\n\n\n
      \n
    1. Watch our CSS file(s)<\/li>\n\n\n\n
    2. Run the command to process the CSS when the files change<\/li>\n<\/ol>\n\n\n\n
      I’m no Turbowatch expert but I found it straightforward to set up.<\/p>\n\n\n
      npm install turbowatch --save-dev<\/code><\/span>Code language:<\/span> Bash<\/span> (<\/span>bash<\/span>)<\/span><\/small><\/pre>\n\n\n
      Let’s make our npm script run Turbowatch instead:<\/p>\n\n\n
        \"scripts\"<\/span>: {\n    \"dev\"<\/span>: \"turbowatch .\/turbowatch.ts\"<\/span>\n  },<\/code><\/span>Code language:<\/span> JSON \/ JSON with Comments<\/span> (<\/span>json<\/span>)<\/span><\/small><\/pre>\n\n\n
      So we’ll need that turbowatch.ts<\/code> file. Fortunately, it’s straightforward:<\/p>\n\n\n
      import<\/span> { defineConfig } from<\/span> \"turbowatch\"<\/span>;\n\nexport<\/span> default<\/span> defineConfig({\n  project: __dirname,\n  triggers: [\n    {\n      expression: [\"match\"<\/span>, \"*.css\"<\/span>, \"basename\"<\/span>],\n      name: \"build\"<\/span>,\n      onChange: async<\/span> ({ spawn }) => {\n        await<\/span> spawn`lightningcss --minify --bundle style.css -o style-min.css`<\/span>;\n      },\n    },\n  ],\n});<\/code><\/span>Code language:<\/span> TypeScript<\/span> (<\/span>typescript<\/span>)<\/span><\/small><\/pre>\n\n\n
      Match files that end in *.css<\/code>, when they change, run the command. <\/p>\n\n\n\n
      Cool.<\/p>\n\n\n\n
      Let’s add a live reloader.<\/h2>\n\n\n\n
      Fair warning, this is extremely old school and definitely not the only option, but I like how easy it is: Live.js.<\/a> <\/p>\n\n\n\n
      It’s a script you link up and it monitors the resources on the page and refreshes when they change. So now…<\/p>\n\n\n\n
        \n
      1. We update our CSS file<\/li>\n\n\n\n
      2. Turbowatcher sees the changes<\/li>\n\n\n\n
      3. Lightning CSS runs and makes a new CSS file<\/li>\n\n\n\n
      4. Live.js sees the change and refreshes the page<\/li>\n<\/ol>\n\n\n\n
        That’s the complete DX we’re after here. <\/p>\n\n\n\n
        Case closed. Lightweight CSS build process complete.<\/p>\n\n\n\n
        About those Lighting CSS features<\/h2>\n\n\n\n
        Bundling<\/h4>\n\n\n\n
        Like Sass, it’s slightly weird that the concatenation\/bundling feature uses @import<\/code>, which is the native CSS syntax. I sort of don’t blame them as otherwise Lightning CSS doesn’t invent any CSS syntax, which is a pretty special line to cross, and would probably mean they’d have to stop using .css<\/code> and use .lightning<\/code> instead or something. <\/p>\n\n\n\n
        I say that, but the conditional syntax<\/a> for imports actually is<\/em> an invented syntax. Strange. Probably would have went with @bundle<\/code> or something then, so that the native @import<\/code> behavior would be preserved. As it is, if you try to use the bundling feature and, say try to use Open Props<\/a> via @import \"https:\/\/unpkg.com\/open-props\";<\/code> or the like, it will error. <\/p>\n\n\n\n
        I still think bundling is a crucial feature here and probably wouldn’t use Lightning CSS at all if it didn’t have it.<\/p>\n\n\n\n
        I can do:<\/p>\n\n\n\n
        \/project\/\n  \/css\/\n    footer.css\n    header.css\n    layout.css\n    reset.css\n  style.css<\/pre>\n\n\n\n
        And style.css<\/code> can bundle those all together during processing as long as they are referenced:<\/p>\n\n\n
        @import<\/span> \"footer.css\"<\/span>;\n@import<\/span> \"header.css\"<\/span>;\n@import<\/span> \"layout.css\"<\/span>;\n@import<\/span> \"reset.css\"<\/span>;<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
        The order is preserved.<\/p>\n\n\n\n
        Syntax Lowering<\/h4>\n\n\n\n
        Lightning CSS makes the choices on what CSS to process down to code that older browsers understand based on what browsers you actually want to support, ala Browserslist<\/a>.<\/p>\n\n\n\n
        Say I want to take advantage of the OKLCH color model (and I do!). I could write…<\/p>\n\n\n
        html<\/span> {\n  --color-dark-purple<\/span>: oklch<\/span>(15.96%<\/span> 0.079<\/span> 316<\/span>);\n  --color-bright-purple<\/span>: oklch<\/span>(45.08%<\/span> 0.24<\/span> 308<\/span>);\n  --color-light-purple<\/span>: #dabbe0<\/span>;\n}<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
        And, as I write, with Browserslist set to defaults<\/code>, the output will be:<\/p>\n\n\n
        html<\/span> {\n  --color-dark-purple<\/span>: #190023<\/span>;\n  --color-bright-purple<\/span>: #7900b5<\/span>;\n  --color-light-purple<\/span>: #dabbe0<\/span>;\n}\n\n@supports<\/span> (color:<\/span> lab(0%<\/span> 0<\/span> 0<\/span>)) {\n  html<\/span> {\n    --color-dark-purple<\/span>: lab<\/span>(2.88618%<\/span> 14.7006<\/span> -16.436<\/span>);\n    --color-bright-purple<\/span>: lab<\/span>(31.5834%<\/span> 65.0634<\/span> -67.2974<\/span>);\n  }\n}<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
        Notice the HEX color was left alone, and the OKLCH values were set into lab()<\/code> instead. I’m not even 100% sure why, but it must be that I’ll get the best cross-browser support of that. That’s nice to not have to think intensely about.<\/p>\n\n\n\n
        It’s not just colors, it’s lots of features of “modern CSS”. Take, for instance, CSS nesting. I can now write:<\/p>\n\n\n
        div<\/span> {\n  div {\n    border-block-start<\/span>: 1px<\/span> solid red;\n  }\n}<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
        We’re close, but not all browsers are supporting native nesting yet. And some browsers right now will choke on that nested selector not “starting with a symbol”. So Lightning CSS will process that to:<\/p>\n\n\n
        div<\/span> div<\/span> {\n  border-block-start<\/span>: 1px<\/span> solid red;\n}<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
        That’s supported everywhere, so fine with me! But notice it left the logical property alone. The browsers you get from the default<\/code> setting all support that, so it’s left alone.<\/p>\n\n\n\n
        Vendor Prefixing<\/h4>\n\n\n\n
        There isn’t terribly much to be said here, but it does what it says on the box. <\/p>\n\n\n
        .mask<\/span> {\n  mask<\/span>: url<\/span>(mask.png);\n}<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
        Turns into:<\/p>\n\n\n
        .mask<\/span> {\n<\/span><\/span>  -webkit-mask<\/span>: url<\/span>(\"mask.png\"<\/span>);\n<\/span><\/mark>  mask<\/span>: url<\/span>(\"mask.png\"<\/span>);\n<\/span><\/span>}\n<\/span><\/span><\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
        Minification<\/h4>\n\n\n\n
        This is a great feature of Lightning CSS, because it saves us from needing a separate tool for this. Plus, they say it’s the best tool on the market for squeezing the size of that CSS down, so bonus<\/em>. Sass always had a “compressed” option for output, but nobody trusted it to truly<\/em> minify CSS. Lightning CSS will do the job nicely. <\/p>\n\n\n
        \n
        \"\"<\/figure>\n<\/div>\n\n\n
        CSS Modules<\/h4>\n\n\n\n
        I figured I’d point out that Lightning CSS can do CSS Modules. I’m a fan of CSS Modules, the way it does scoped styles is very useful, but generally only in the context of React where I’m in a position to import<\/code> the styles and apply the proper className<\/code>. For a very simple CSS processing like this, which doesn’t involve the HTML or templates in any way, we don’t need CSS modules.<\/p>\n\n\n\n
        Example Project<\/h2>\n\n\n\n
        Wanna see all this functional on a project so you can copy the bits you need like we all do every day? Heck yes, you do:<\/p>\n\n\n\n
        \n
        Example Project on GitHub<\/a><\/div>\n<\/div>\n","protected":false},"excerpt":{"rendered":"
        If you need a mini build process just for your CSS, Lightning CSS is a pretty good modern choice. That, plus a file watcher and live reloader offers pretty good DX.<\/p>\n","protected":false},"author":1,"featured_media":134,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"sig_custom_text":"","sig_image_type":"featured-image","sig_custom_image":0,"sig_is_disabled":false,"inline_featured_image":false,"_jetpack_memberships_contains_paid_content":false,"footnotes":""},"categories":[1],"tags":[34,7,33],"class_list":["post-126","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-blog-post","tag-build-process","tag-css","tag-lightning-css"],"acf":[],"jetpack_featured_media_url":"https:\/\/i0.wp.com\/frontendmasters.com\/blog\/wp-content\/uploads\/2023\/11\/lightning-featured.png?fit=1000%2C500&ssl=1","jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/frontendmasters.com\/blog\/wp-json\/wp\/v2\/posts\/126","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/frontendmasters.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/frontendmasters.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/frontendmasters.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/frontendmasters.com\/blog\/wp-json\/wp\/v2\/comments?post=126"}],"version-history":[{"count":16,"href":"https:\/\/frontendmasters.com\/blog\/wp-json\/wp\/v2\/posts\/126\/revisions"}],"predecessor-version":[{"id":986,"href":"https:\/\/frontendmasters.com\/blog\/wp-json\/wp\/v2\/posts\/126\/revisions\/986"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/frontendmasters.com\/blog\/wp-json\/wp\/v2\/media\/134"}],"wp:attachment":[{"href":"https:\/\/frontendmasters.com\/blog\/wp-json\/wp\/v2\/media?parent=126"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/frontendmasters.com\/blog\/wp-json\/wp\/v2\/categories?post=126"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/frontendmasters.com\/blog\/wp-json\/wp\/v2\/tags?post=126"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
    Let’s use Turbowatch<\/a> to:<\/p>\n\n\n\n