Compiling A number of CSS Recordsdata into One

Stu Robson is on a mission to “un-Sass” his CSS. I see articles like this pop up yearly, and for good motive as CSS has grown so many new legs lately. A lot in order that a lot of the core options that will have prompted you to succeed in for Sass prior to now are actually baked instantly into CSS. In truth, we’ve Jeff Bridgforth on faucet with a associated article subsequent week.

What I like about Stu’s stab at that is that it’s an ongoing journey slightly than a wholesale swap. In truth, he’s out with a brand new put up that pokes particularly at compiling a number of CSS recordsdata right into a single file. Splitting and organizing types into separate recordsdata is certainly the rationale I proceed to Sass-ify my work. I really like having the ability to discover precisely what I want in a particular file and updating it with out having to dig by way of a monolith of fashion guidelines.

However is that an actual motive to maintain utilizing Sass? I’ve truthfully by no means questioned it, maybe on account of a lizard mind that doesn’t care so long as one thing continues to work. Oh, I would like partialized type recordsdata? At all times accomplished that with a Sass-y toolchain that hasn’t let me down but. I do know, not probably the most proactive path.

Stu outlines two methods to compile a number of CSS recordsdata once you aren’t counting on Sass for it:

Utilizing PostCSS

Ah, that’s proper, we are able to use PostCSS each with and with out Sass. It’s simple to overlook that PostCSS and Sass are appropriate, however not depending on each other.

postcss predominant.css -o output.css

Stu explains why this may very well be a pleasant approach to toe-dip into un-Sass’ing your work:

PostCSS can seamlessly combine with common construct instruments like webpack, Gulp, and Rollup, permitting you to include CSS compilation into your current improvement workflow with out potential, further configuration complications.

Customized Script for Compilation

The last word factor could be eliminating the necessity for any dependencies. Stu has a customized Node.js script for that:

const fs = require('fs');
const path = require('path');
// Perform to learn and compile CSS
perform compileCSS(inputFile, outputFile) {
    const cssContent = fs.readFileSync(inputFile, 'utf-8');
    const imports = cssContent.match(/@imports+['"]([^'"]+)['"]/g) || [];
    let compiledCSS = '';
    // Learn and append every imported CSS file
    imports.forEach(importStatement => {
        const filePath = importStatement.match(/['"]([^'"]+)['"]/)[1];
        const fullPath = path.resolve(path.dirname(inputFile), filePath);
        compiledCSS += fs.readFileSync(fullPath, 'utf-8') + 'n';
    });
    // Write the compiled CSS to the output file
    fs.writeFileSync(outputFile, compiledCSS.trim());
    console.log(`Compiled CSS written to ${outputFile}`);
}
// Utilization
const inputCSSFile="index.css"; // Your predominant CSS file
const outputCSSFile="output.css"; // Output file
compileCSS(inputCSSFile, outputCSSFile);

Not 100% freed from dependencies, however geez, what a pleasant approach to scale back the overhead and nonetheless mix recordsdata:

node compile-css.js

This strategy is designed for a flat file listing. For those who’re like me and like nested subfolders:

With the flat file construction and single-level import technique I make use of, nested imports (you are able to do with postcss-import aren’t vital for my venture setup, simplifying the compilation course of whereas sustaining clear organisation.

Very cool, thanks Stu! And take a look at the full put up as a result of there’s a variety of useful context behind this, notably with the customized script.

Direct Hyperlink →