Current situation:
We have 1 application that generates sass files, which is then obviously compiled into CSS and uploaded to 1 CDN location. This is done by "us" (the design team).
There are multiple applications that use this css CDN. This is done by the devs, who just import said CDN, ready to use. (To clarify: the solution can not involve anything on the dev-end.)
This one CDN contains
basic stuff that all applications need (color variables, mixins, etc)
application specific styling: meaning there are rootclasses (.application-1 {}, .application-2 {},...) that contains everything for that specific application, so it doesn't interfere with anything else
Now as you might imagine, that one CDN is becoming very bulky and every application is loading all styles for all applications which is unnecessary heavy.
So what we want:
1 CDN with the general stuff that every application will use
multiple CDNs for application-specific stuff
The problem:
Since it's SASS that we use, I can't just say to gulp to generate separate files and be done with it because the specific SASS relies on the mixins and variables of the general SASS.
I hope this is clear, it's a tad difficult to explain properly. I'm hoping someone has had this same issue and can tell me how they solved it.
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)
},
]
}
I have two large projects, each project has a relatively simple web front-end with multiple themes: different colors and fonts. These themes are the same across projects
One of these projects uses scss and the other uses less. Neither are my strong suit and i am not allowed to make them use one or the other in both places. What i would like to do however is have a shared folder with a file for each theme which could hold all the variables for that theme.
This would allow me to avoid duplication and make maintenance slightly easier, while promoting consistency between the two projects which must have the same colors and fonts between them. Is there a relatively simple way of doing this?
You should read the SASS and LESS documentation. You'll see that SASS and LESS although similar both have different ways of declaring variables. So Importing a LESS file to a SASS file, and vice-versa, will not have the result you expect.
I would suggest, since it's an easy change, adapting the LESS file to a SASS file or a SASS file to a LESS file and create the base for what you want from there.
I have a website which uses 1 css file, it is called body.css and it consists of 841 lines. Should it be sorted in different files (header.css, footer.css page1.css, etc...), is it better in just 1 file or does it not matter?
The only thing I know for sure is sorting it in more files is a lot more readable.
Also if someone answers this I'd be most grateful for a little explanation.
My opinion would be one of two things.
1) If you know that your CSS will NEVER change once you've built it, I'd build multiple CSS files in the development stage (for readability), and then manually combine them before going live (to reduce http requests)
2) If you know that you're going to change your CSS once in a while, and need to keep it readable, I would build separate files and use code (providing you're using some sort of programming language) to combine them at runtime build time (runtime minification/combination is a resource pig).
With either option I would highly recommend caching on the client side in order to further reduce http requests.
So, there are good reasons in both cases...
A solution that would allow you to get the best of both ideas would be :
To develop using several small CSS files
i.e. easier to develop
To have a build process for your application, that "combines" those files into one
That build process could also minify that big file, btw
It obviously means that your application must have some
configuration stuff that allows it to swith from "multi-files mode" to "mono-file mode".
And to use, in production, only the big file i.e. Single CSS
Result : faster loading pages
maybe this will help you..
For optimal performance it is better to have only one css file.
But for readability it would be better to have different files for different parts.
Take a look at tools like SASS, which help do that without sacrifice performance. Additionally it has features to make your files even more readable by introducing variables, function and much more.
Using more files means more requests. It will take more time to load and make unnecessary requests to the server. I'd stay with one file.
The only good reason to have other css files would be if you have third-party components, to keep them separated and be able to update them easily.
The order matters: Rules loaded later will override rules with the same name loaded before (this is valid even for rules in the same file).
What do you mean that your website uses one CSS file? Normally you'd write your style definitions in multiple files, and they are concatenated (or not) into one file. My point is, what you are working on in your development environment should stay modular, readable, it shouldn't be influenced by what you have in production.
As for the order of the CSS files, yes, it matters, as you can overwrite your previous definitions.
For optimal caching I'd recommend you to build all the vendor CSS in one file, and your CSS in another file, versioned, so that if you change something in your code, only that file has to be updated by the browser.
But these things depend on the infrastructure. As the browsers are able now to send multiple requests simultaneously, having multiple files can lead to faster page load than only one. But I'm not sure about this.
you might want to take a look at gulp to automatically optimize, and minify your CSS code.
All css in one file is OK.
But it's free : you can make as many css file as you want.
However usually this is how it is:
1 global css file for the entire page. You put the common css in here that is useful for every page on your site. You can call it app.css or style.css or mywebsite.css or any name you want.
1 specific css file for a specific page when you want to specially separate this css from the global css file. Because it will contains css only useful for a few pages. For example you have a special component made by your own or a special functionnality. Example : you have made a spcial javascript code working with some html for uploading some file and you want to have your code js/css separate.
Usually, you can also have one css page for each page, but always one global css file for the entire site.
Note : Same question is also valid for javascript
Note 2 : You can also think about using a framework to minify your javascript and css into one single css / js file at the end. At work our technical boss use wro4j which works for java but it should exists many more other frameworks as you can search on google.
I am building an app in Rails 4 and am using asset pipeline. For my workflow, I've split my css into 10+ separate sheets. Should I combine them for deployment or does it not matter as long as they're minified? I'm wondering how much performance will be affected with separate stylesheets.
Have a look here:
http://guides.rubyonrails.org/asset_pipeline.html#precompiling-assets
The default behavior is to combine your CSS files for you in production, into one asset with a hash on the end to make sure it updates when you change the files.
For example, here is my company's css file:
http://quickleft.com/assets/application-ff836a79f9021feeab313402499df444.css
but in our assets/stylesheets folder we have 20+ individual files to keep ourselves organized.
Combining and minifying your CSS is important though, as it can significantly reduce the bytes needed to be sent over the wire to the browser.
Check this article out on bundling: http://www.asp.net/mvc/overview/performance/bundling-and-minification. Even though the article is about bundling in .NET, the browser/performance related concerns are applicable.
In short, browsers can only get 6 resource files at a time so, even though you have your stylesheets minified making the file size smaller, performance will be affected because of the limit of files a browser will retrieve at one time.
Im just trying to confirm if I understood #import correctly,
Basically what It can do for you probably at least one of the things is to give your css some structure by separating the different layouts in separate categories.
Right now each of my css files look insane, I have about 10 of them for one site and alot of them are using up space for the same code and only some new stuff have been added.
I am guessing that I can use #import to only add style where it is needed?
Yes, it works pretty much like include or require functions in PHP.
You can separate your style in multiple files and include some of them where it's needed.
Unlike PHP, CSS use HTTP requests to import files, which means your site will be slow if you separate your CSS to many files (try to keep it up to 3, but only 1 is ideal).
I suggest you to separate files only during the development period which would allow you to manage your files easier, but put everything into 1 file before launching your site.