I'm working on a site that uses Gulp to compile its SASS, among other things. It was set up by another developer on my team. I am brand new to Gulp and don't use SASS much either. However, getting it up and running was easy.
The one problem, though, is that when I ran Gulp, even though I hadn't changed anything in the source files, it changed pretty much every generated CSS file in the project. Every file had /*! typey | GPLv2 License | https://github.com/jptaranto/typey */ added at the top, and there were many files where numeric values changed by a tiny bit (like skewX(0.39063deg) → skewX(0.39062deg)). And it also added hundreds of *.map files which didn't exist before.
This has happened to me before using Compass too. It pretty much makes looking at the diff useless to see any actual changes. Is there a way to unify the output of our Gulp so this doesn't happen?
Related
I'm using Codekit to minify all my CSS via Sass. This works great but causes an issue when inspecting the code as everything appears on line 1! I use the lines as a quick way to find the code I'm looking for.
I use the Codekit plugin for Coda, which means every time I make a change to a .scss file and save, it just auto compiles the code.
I guess everyone will tell me not to compile the code until launch, in an ideal world that's great but there will ALWAYS be a need to inspect the code without once it's all been compiled.
Is there a way around this? Or is this a downside of compiled code? What processes do people go through to get to the minified code? How can I tell which .scss the change is in?
I could set it to be less compressed so it's not all on one line but I would then lose the benefits of compressing it.
These are the settings I have Codekit set to:
Codekit supports Source Maps, which will let Google Chrome show you the original code even after minification.
In your compilation settings, check the Create a source map box for SASS.
For more information, check out this Team Treehouse article (the article deals with JavaScript, but the same principle applies to CSS too) and the Codekit SASS documentation.
I'm using Visual Studio 2013 with latest Web Essentials. I chose to partition my CSS into separate LESS files, and create a build.less which includes all my stuff. Now when I edit and save for example tables.less, Web Essentials will automatically compile it, adding a lot of "junk" css files to my web project.
I would like to exlude all of my LESS files from compilation except for the build.less one. Of course I know that as a side effect I have to always do a dummy CTRL-S on my build.less, but that's a fair tradeoff for being able to structure my code.
I've checked all of the options of WE related to LESS compilation without success till now. Are there any "hidden" tricks or some LESS preprocessor directives to make it work this way?
Rename the file to start with an _.
Or what is the best practice to "import" a less file in sass files?
I'm building a rails project with SASS as the solution for writing syntactic css. The SASS parts worked fine, until I find out that the styles of some open source projects are written in LESS and I really want to reuse their artwork.
Should I just let Rails precompile all LESS and SASS files, and require the result css files in a specified order?
The license of these third party projects are different. Understanding all the details about intellectual property laws seems to be too much work for the small project I'm doing (e.g. should I keep a css file MIT licensed if I changed 90% of it and just used the color palette?), this project will be open sourced as well, so I would like to keep the codes untouched for now.
Update: A easy way of translating all LESS files to SASS files would be nice as well.
From my understanding, LESS & SASS are compiled differently (although are similar)
Would you be able to translate the LESS files you wish to include?
By default SASS looks at the filename and determines whether to make a css file out of it. I'm wondering if there is a way to prevent this from happening.
We're building a large website and lots of front-end developers are editing the css, but we only have one dev server. Sure some things you can see happen locally, but often you can only see the real rendered way on the server.
So, when I push my compiled css file to the server, my co-workers' css gets clobbered until s/he commits and I do an svn:update, etc, etc.
However, if we were working in different SASS file, and those css files were getting created, I would only have to push up, say, the forms.css file instead of the whole thing.
Then for Production, we'd put it back to the way SASS normally works.
The only other way I can figure to do this is to do a mass rename of files, which seem very messy.
Thanks in advance.
The entire point of partials is that they don't get compiled into files. If you want a sass file to be turned into a css file, remove the underscore.
Your real problem seems the be that you're putting compiled CSS in your version control. Don't do that. Only commit Sass, and compile it into CSS server-side with a post-receive hook or something.
I'm considering using less in an upcoming project but have been trying to figure out the best way to work with it while in development.
Usually when developing a site I'll write my html and css then start testing it in the browser, see how it looks, refine, reload, and repeat the whole process until I'm happy with how everything looks.
A crucial part of the process is using the Inspect Element feature in the browser to identify the piece of CSS I need to change. Usually just by looking at the line number I know exactly where to go in my CSS file.
But if I use Less (or any other method of combining/compressing my CSS) it makes the line numbers useless. I know I could use Find to search for the section of code but line numbers are much faster.
This is especially true when working on a project that involves other developers or large CSS files.
I just wondered how others deal with this, or maybe there's a better process?
Minified CSS really should only be going out to the production version of your site. When you're performing tests/changes etc, this should all be done in some test or development version of your site in a secondary server area where you can have the line-numbers version of css available. The same would go for JavaScript. On the production viewable copy, you want it minified. In development, you don't.
In any event, you should always have 2 copies of your css. The first copy is the primary source copy that is your development copy. It has all of your properly formatted styles with line-breaks in it. The other is the very latest minified version of your css that went to production. This will allow you to switch between the 2 files rapidly in the event that you need to work something out, assuming your site uses some sort of templated delivery (layout pages, master pages, or whatever).
The minified version will only be useful in the final delivery. All other needs should use the master copy. It might not be a bad idea to put a configuration in server-side portion of your site that determines what style sheet to use. That way you can simply change a configuration setting and go into a "debug" mode.
I agree with Joel - that's how I handle it. A build script minifies the CSS (and JS) before each release is FTP'ed to production. I just have a switch in PHP like:
if ($config->prod()) {
// incldue the minfied css
} else {
// include all the original files
}
Personnaly, I use an ant build script to make a production version:
it "condense" multiple css files in one
then it minify them with YUI compressor
same for scripts
(page recomposition to point to the newly generated files)
this way you divide your http request for those files, and gain some bandwith from 30% to 70% i'd say. depends on gzip also.
in my case, the dev version have:
18 css weighting 178ko
reduced down to 1 css at 96ko in the production version
I personally use tools to minify and inject the CSS into the browser each time i save my Less file. So i see each change immediately. This way it's pretty clear what just happened. I don't need the referencing line numbers that much any more.
I recently started using source maps, to see the correct file and line numbers (of my less files) when inspecting CSS in the browser again. I think that is what you are looking for. I personally don't need this extra fanciness that much.