Stu Robson is on a mission to “un-Sass” his CSS. I see articles like this pop up yearly, and for good cause 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 straight into CSS. In actual fact, we’ve got 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 change. In actual fact, he’s out with a brand new submit that pokes particularly at compiling a number of CSS recordsdata right into a single file. Splitting and organizing kinds into separate recordsdata is certainly the rationale I proceed to Sass-ify my work. I really like with the ability to discover precisely what I would like in a selected file and updating it with out having to dig by way of a monolith of fashion guidelines.
However is that an actual cause to maintain utilizing Sass? I’ve actually by no means questioned it, maybe resulting from 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 will use PostCSS each with and with out Sass. It’s simple to overlook that PostCSS and Sass are suitable, however not depending on each other.
postcss primary.css -o output.css
Stu explains why this may very well be a pleasant option to toe-dip into un-Sass’ing your work:
PostCSS can seamlessly combine with well-liked construct instruments like webpack, Gulp, and Rollup, permitting you to include CSS compilation into your current improvement workflow with out potential, extra 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');
// Operate to learn and compile CSS
operate 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 primary CSS file
const outputCSSFile="output.css"; // Output file
compileCSS(inputCSSFile, outputCSSFile);
Not 100% freed from dependencies, however geez, what a pleasant option to scale back the overhead and nonetheless mix recordsdata:
node compile-css.js
This method is designed for a flat file listing. In case you’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 needed for my undertaking setup, simplifying the compilation course of whereas sustaining clear organisation.
Very cool, thanks Stu! And take a look at the full submit as a result of there’s a variety of useful context behind this, notably with the customized script.