Let's say I have a large Sass/Less project such as Bootstrap, and I want to use one single element of it, (say, a text box.) Is is possible to have Sass/Less compile just the classes needed for that, referencing whatever variables and mixins that are across multiple files, just to compile that 1 (or 2, or 5, or 10) class(es)?
You could create mixins that aren't executed immediately by adding parenthesis. In my less library, I use a node script to create an autoload.less file which I can reference.
From there, I create my final classes as:
#import "autoload.less";
.myClass {
#myLessModule > .aMixin();
}
I don't think this is a perfect solution but it is working fairly well for me, and the resulting stylesheets do not contain excess stylings.
There currently aren't any features in Less/Sass to accommodate this. What you are looking for is a post-build process to remove unused CSS classes. The most notable currently is Uncss which has plugins available for most build tools (Gulp, Grunt, etc)
Related
I'm using CSS Modules (Sass) with rollup on a component library project, which is working well. Each component ends up with a dist folder containing a single JS bundle file, and a corresponding CSS file with the scoped CSS classes so consumers of the component don't have to worry about CSS class name conflicts. All they do is include the JS bundle and the CSS file and everything is great. Yay CSS Modules.
The problem I'm now facing is that some components really need separate "themes" - ideally, separate CSS files, one per theme. So consumers can continue as they've been doing: including the JS bundle, but now choosing which CSS file to include to pick a theme.
I'm not sure how to get this going with CSS modules & rollup, and whether this is even the sort of approach others are taking. From what I can see, rollup always handles bundling things together, whereas I want separate CSS files, all of which get their classes renamed identically during the build phase. That way, if within my JS I refer to styles.myclass, if myclass had gotten renamed to scoped-myclass by CSS modules for the original CSS file, for a second CSS file it would also get the same name.
This would keep consumption of the component extremely simple - just a matter of including a different CSS file.
Any suggestions?
Awfully late, but let me answer this 3 years on. So what I ended up doing was totally detaching the CSS generation step from rollup and relying on the Sass CLI to handle that portion of the build process. It felt a bit klutzy, but I remember it wasn't awfully hard to do and solved the problem I outlined above. I don't believe there was a plain rollup solution at the time, nor do I think there's one today.
However... in my case the whole approach was kinda mistaken. This certainly won't be everyone's scenario, but let me spell it all out because hey it may be useful and it definitely wasn't obvious to me at the time.
This was for an in-house shared component library, where each component and its corresponding CSS was a separate npm package stored in our Artifactory. When it grew, plenty of internal references popped up, e.g. multiple components would reference the Button component, and over time they'd reference different versions of the Buttons component - each of which needed its own properly scoped CSS, unique to that package-version.
So what I found was that by doing it this way - having the CSS generated as part of the npm package dist files - I had to write an additional layer for the consumer applications that would parse their node_modules/ folder for our own internal components and combine all the different CSS files, such as the multiple versions of buttons. e.g. the main application would directly import buttons v1.0.0 in its package.json file, but the Dialog component (also included in the package.json) could include buttons 2.0.0 as its own dependency. For every version of the package, there was a uniquely scoped version of the CSS - so the consuming application HAD to include every version otherwise the styling would be borked.
So all in all, it ended up being way more complex that I wanted. I thought I could make it easier & better with the separate generated themed CSS files as part of the package dist, but it didn't end up that way. If I could revisit that project today, I'd re-examine a solution used by Material UI and others which I kinda poo-poo'd at the time: automatic injection of the CSS into the page by the component JS, rather than generating standalone CSS files which required extra work by the consumer applications to gather up and add to the final webpage. Frankly, now I regard it as the "least crap". There are definite downsides to the injection approach (extra work done on every page render for everyone! Yikes!), but there's no doubt in my mind it hugely simplifies the job of the consumer applications. It's a balancing act, but in 20-20 hindsight I'd lean towards the injection approach. With that, scoping & theming is a different and much simpler problem.
If I got you right, consider looking at SCSS plugin: rollup-plugin-scss. It captures all spare .css files imported in the components, and then processes them through underlying node-sass. The catch is, it seems like you can write a custom callback function that'd handle your CSSs differently based on conditions you throw in.
Based on the example from the plugin's page:
import scss from 'rollup-plugin-scss'
...
export default {
input: 'src/index.tsx',
output: [...],
plugins: [
...
output: function (styles, styleNodes) {
// replace this with conditioned outputs as needed:
writeFileSync('bundle1.css', styles)
writeFileSync('bundle2.css', styles)
},
]
}
What I have is a large CSS file which was compiled from Sass. I have some of the original Sass files, but looking at the source map not all of them.
I'm able to compile the Sass that I do have into CSS, but of course some of the style rules are missing.
How can I reduce these two files into only the rules that are unique to the original? I would like to be able to do that so that I can include that CSS with the source Sass I have on hand to speed up future development.
I would do it like this:
take original CSS and convert it to Sass by changing extension to .scss
if original CSS is minifed use something like CSS Formatter to get readable code
name it something like legacy and import first in your master Sass file
use nanocss in your build process to dedupe duplicate styles (make sure discard-duplicates plugin is enabled)
optional: enable dedupe only for production build since it slows down CSS generation
drawbacks:
if changing properties on existing classes in Sass dedupe will not match against legacy and you end up with almost-duplicates - to prevent that, I would manually go into legacy to delete old classes when changing them in sass partials
Based on your input you should do following "backwards-engineering":
1) Compare you CSS files in a diff-program, e.g. diffchecker.com (let us call your files: file1.css and file2.css).
2) The diff-program will mark duplicate areas with color.
3) Decide which file to update and remove the duplicates, in that file.
Note!. This method will only solve if you have duplicated text blocks in your CSS files. It will not solve to "clean & improve" e.g. if you have spreadout "duplicate" information.
This question already has answers here:
How can I define colors as variables in CSS?
(19 answers)
Closed 8 years ago.
What is the cleanest easiest way to declare a variable in CSS with meteor? Between the two CSS compilers SASS and LESS, which one can allow me to declare variables so I do not need to define exact values, instead, have control from a variable. For example...
variableNameOne: value;
variableNameTwo: value;
.sidebar-nav li a {
color: variableNameOne;
}
I do not wish to do anything more advanced than this in css. I am using boootstrap in meteor.
CSS3 apparently supports variables by declaring them at the top of the styling sheet inside :root {varName: value;} but it is not supported in all browsers as far as I have read.
Is this the best practice to install nemo64's bootstrap and less? sourced from http://www.manuel-schoebel.com/blog/meteorjs-and-twitter-bootstrap---the-right-way
// 1. Add the less compiler so meteor compiles everything for you
meteor add less
// 2. Add the bootstrap
meteor add nemo64:bootstrap
// 3. Clone this stylesheet boiler
// Also delete the .git folder and .gitignore if you don't like those
cd yourapp/client/
git clone https://github.com/DerMambo/stylesheets.git
// 4. Add everything you need into the file
// yourapp/client/vendor/custom.bootstrap.json
I would strongly advise using a CSS precompiler, once you start using it you'll never want to go back.
Since you're using bootstrap, I'll list the 2 CSS precompilers that bootstrap provides support for : LESS and SASS.
LESS :
Probably the easiest solution, LESS is baked into Meteor (just meteor add less and throw .less and .import.less files in your sources) and it provides every feature you'll probably need if not a CSS guru.
I recommend this package https://github.com/Nemo64/meteor-bootstrap to integrate a LESS customizable bootstrap in your app, you'll be able to override bootstrap variables (colors, responsive breakpoints, and a ton of other things just by changing variables values, no more dirty CSS hacks with !important).
SASS :
Sass is considered superior to LESS as far as features are concerned and is probably a better choice in the long term if you plan to spend times in web application stylesheets design.
There is package that adds support for Sass source files compilation within a Meteor app (https://atmospherejs.com/fourseven/scss), and you should be able to find a decent bootstrap-sass package too.
Be aware that Meteor Sass is based on node-sass which is based on libsass, a reimplementation of the original Ruby Sass in C++, which is not exactly up-to-date with the regular Ruby implementation, but this should hardly be a problem since only pretty advanced features lacks support in libsass.
Please note that this is an ultra-short presentation of CSS precompilers and thus subject to primarily opinion-based comments.
I have an issue with sass compilation.
When I have a project with a partial _partial.scss and have it imported in multiple partial files (because it contains color variables) it will end up in the compiled css multiple times!
This is ugly because the same rule will 'overrule' itself multiple times which makes debugging info (chromium dev tools / firebug) rather unreadable.
I presume there is a solution for all this. I just can't find anything on the issue, anywhere.
The solution is to either not include the same file multiple times or don't have any code that directly outputs CSS in the file you're planning on including more than once. If your variables were in a file by themselves, they could be safely included anywhere you'd like without selector duplication.
Maybe this #mixin helps you: https://github.com/wilsonpage/sass-import-once.
Have a look at the example and note how the reset is only included once in the final CSS.
It seems that just for this, sass (and thus, scss) now have #use instead of #import. From the #use documentation (emphasis is mine):
The simplest #use rule is written #use "", which loads the module at the given URL. Any styles loaded this way will be included exactly once in the compiled CSS output, no matter how many times those styles are loaded.
Sass also discourages further use of #import:
The Sass team discourages the continued use of the #import rule. Sass will gradually phase it out over the next few years, and eventually remove it from the language entirely. Prefer the #use rule instead.
Any projects having this problem could try running the module migrator tool and check if the problem is resolved.
I have an existing Django project which uses regular CSS. The style sheets are broken up by functionality, so there is a nav.css, course.css, default.css, reset.css, etc. All of these are imported in a main.css, which is referenced from the html pages.
I would like to use Compass in this project so I can make the style sheets more manageable and also make it easy to skin the UI.
Before checking out Compass, I looked into Sass, and created .scss files for all my style sheets.
Now I realize that it may be better to use Compass than just Sass, because I will get all the default styles that come with it. However, I am a bit confused about how to start the refactoring process.
What would be the right process to refactor (in baby steps) an existing project which already has its styles defined, to get it to use Compass?
Much of the refactoring work is the same with or without Compass and you'll see the benefits that Sass offers sooner than those of Compass.
Compass creator Chris Eppstein did a write-up of how he went about refactoring digg's CSS. To sum up:
Extract partials. You're well on your way with this one, since you already have separate stylesheets for different functionality. Go further and pull out independent sets of rules to make them easier to manage and break down the refactoring project into smaller steps.
Analyze styles. Look for repeating patterns and inheritance relationships in your new partials. Wherever you have selector duplication could be a good place to start the next step.
Extract base classes. This is where you DRY up your CSS with #extend. Pull out duplicated declarations into a base class and extend.
Apply nesting. Nesting is a great Sass feature to make your stylesheets easier to read.
Extract mixin. If you found common styling patterns in step 2, this is the time to extract them into mixins.
Now you can really start taking advantage of Compass and its reusable patterns. Familiarity with the Compass documentation will help to identify which of the mixins are applicable to your project.