When you do a compass compile after renaming or deleting files the compiled files won't actually get removed. compass clean doesn't actually remove these files either since it only worries about cleaning up what is currently in use. That being said I don't want to do something like a rm -rf /css/* where css is my compiled folder either since that blows away all my files completely.
I am wondering if there is a way to just delete the "old" compiled files without touching anything currently in use.
Why?: if you have lots of scss files the generated files or sprite sheets might take some time to generate. This isn't too bad, but if you are then taking the generated files and creating some other derivative of it (maybe because you have some older build process or are generating docs or something else) then you need to completely regenerate all of it again. Blowing away all the files forces a complete regeneration; whereas, only removing un-needed files and then recompiling is extremely quick.
We are toying with the idea that blowing away all the files only on occasion by doing the following:
compass clean
rm -rf css/*
compass compile
But we are hoping for a better solution :).
A shell script to remove the CSS files and generate new ones would look like this:
#!/bin/sh
compass clean
compass compile
Note that this particular script needs to be in the same directory as your project to work. My script-fu is pretty weak, but I'm sure it could be modified to work anywhere without having to copy/paste it in every project.
Related
I'm very new to scss and css so please bear with me. I've done some research but found conflicting information.
I have 2 freelancers working on my project. Both freelancers make changes to:
style.css
style.css.map
style.scss
Everytime I merge their work I break the frontend. How can I merge their work without breaking everything?
I read online that these files should not be included in GIT? I also read that I should used GULP or LESS? Apparently, I should compile the merged code before committing? Seriously confused with the research.
How do I handle these files?
The .css file is generated from the .scss files.
Your developers should commit only in the .scss files.
In the most cases the .css file is not added to the repository at all. And you should not modify the .css file directly because it will be replaced with the next compilation of .scss the files.
GULP is just the tool that compiles the .scss files and create the css from them. Basically when using GULP you can create some functions where you can specify the input location(.scss), output location(.css) and additional rules, etc.
There are also other tools that can do this. Like Koala, Webpack.
You probably should not store generated files in git. In this case, the generated files would be the .css and .css.map files that compass (I'm assuming you use compass because of the tags) generates for you. You should store the .scss file in source control, and compile it to .css afterwards.
If the freelancers are making direct manual changes to the .css files, they should know that at each recompile those changes will be lost.
I have split my less/css into several files grouped by certain categories, so the single files stay easy to maintain. Though I only want to have one css file which gets imported into the layout.
For this I have - how I call it - a master less file which imports all the others like config, forms, layout and so on.
Now the problem is, that for example WinLess or all the other copilers i tried, only monitor the save of my master file, and only then compiles it. However this is stupid, because this file nearly never gets any changes. So what I would like to have is something, that detects changes on the imported less files and then only compiles the master file.
Does anyone know any tools, which are capable of that?
Or how do you manage your less files to bypass this problem?
Further Info: I have mapped the server directory locally via SSH and edit the files in there, i.e. the files are only pseudo local. They are on the server but accessible with a local path over a drive letter. The compiler should be able to work with that setup.
Thanks for the answers!
In all honesty, your best bet is to actually use Less's own compiler which will of course be the most up to date option. It will be done through command line but it's the best way to know that everything is correct, working and up-to-date.
All the information can be found in the Less Documentation Here
More information about compiling with imports can be found HERE
The latest version of WinLESS does report that it has automatic re-compiling when an #import file is changed so it could be that your version of WinLESS is out of date. (See HERE - 3rd bullet point under Features)
Alternatively, see if you can get it to work on purely local files. If this works, it may be an issue with the compiler not being able to do asynchronous checks over SSH.
I use Notepad++ with the NppExec-plugin on-save script. If you make a convention decision to always name your primary file "master.less" you can use this script:
NPP_CONSOLE 0
NPP_SAVE
if $(EXT_PART) != .less goto end
"C:\Node.JS\node_modules\.bin\lessc.cmd" -x "$(CURRENT_DIRECTORY)\master.less" > "$(CURRENT_DIRECTORY)\master.min.css"
:end
You can do something similar with any editor that supports batch scripting (like Stewartside suggests)
I'm working on a project (by myself, and in two different machines) where I'm using Gulp, and the gulpfile has two main goals - generate the build (default task) and compile SASS to CSS, within the /app (source) folder.
Any advice on avoiding people (me included) to update a .css file that would be eventually overwritten by a compiled .scss file with gulp-watch?
I'm also using Git and recently I lost some changes I've made to a CSS file for that reason. I'm not sure what happened, but when I merged commits, some CSS was lost and I had to look for it in previous commits. No big deal, and it was actually my fault, because I made some commits without checking out the origin, and then pushed them.
A part from the CSS issue, does it sounds like a good workflow? It feels good to work with that level of organisation and make profit of Sass, Gulp and Git, but sometimes it feels I'm making things too complex, not sure if that's the case, or if I'm doing something wrong or if it's just a matter of familiarisation.
First of all, if you are using SCSS, why are you editing CSS files?
I would recommend adding your CSS files to .gitignore so that they are not committed and only commit your scss files. You just have to remember to use gulp to generate new css files whenever you checkout your repo into a fresh project.
As far as, keeping people (including you) from editing a css file... just don't do it. You and anyone else familiar with a project should know that your css is overwritten by scss compiling.
TL;DR: IItemTransform isn't getting executed when a minified file already exists in the same folder as the original (non-minified) file.
Problem explanation
I'm having this issue mainly because of CSS relative image references. If you used IItemTransform with Javascript files, the same applies.
This is what I'm using:
I'm using Visual Studio with Web Essentials addin to have support for LESS files
I'm writing LESS files and have Web Essentials addin automatically minify files on save
I'm also using bundling and minification in my project
When creating CSS bundles I'm using CssRewriteUrlTransform to make CSS URLs absolute (i.e. background images) so that images still work after bundling several CSS files together
Nothing unusual here so far, but it doesn't work.
What seems to be the problem?
The way that bundling and minification works is it tries to avoid excessive processing. This means that when a minified file exists in the same folder as the original one it won't run its own minification and rather serve existing file.
This would be all right as long as it would at least run transforms over those preexisting minified files. But it doesn't. So I end up with relative URLs in a bundle which breaks pretty much all those resources.
Workarounds
Always provide absolute paths in LESS files
Disable file minification on save in Web Essentials settings
Refer to minified files when defining my bundles because they don't have a minified version (*.min.css doens't have a *.min.min.css) so minifier actually picks up the file and minifies while also running transformations over it.
From the standpoint of my development process and tools used (and configured the way they are) this looks like a bug. If those files would be the result of the same minification process this wouldn't be a bug at all as transformations would be executed when minification would execute. It's true that such functionality doesn't exist and likely never will as app would need write permissions to make it work. Outcome: this is a bug. Existing minified files should be processed through transformations before being cached.
Question
Is it possible to somehow convince bundling and minification to either:
not use existing minified file versions
run transformations over existing minified versions
Have you considered using Grunt? http://gruntjs.com/
It has a learning curve, but, the information pool is huge. The issues that you are having with web essentials wouldn't be a problem with grunt.
I'm using it in VS, now, to minify, bundle and transpile both css and javascript as well as reorganize files into a deployment directory. Once you've set up a directory structure, a grunt file could very easily be reused.
With the add-on in VS (linked, below), you can right click on the grunt file and select the grunt tasks to run from a popup menu.
https://visualstudiogallery.msdn.microsoft.com/dcbc5325-79ef-4b72-960e-0a51ee33a0ff
Grunt "tasks" as they are called can be created by downloading various plugins i.e. https://www.npmjs.com/package/grunt-contrib-less.
I have never used LESS or web essentials, so please take this post for what it is worth (not much.) Could you add a pre-build command to simply delete the old files, then do a rebuild when you need to update the CSS.
I was hoping to find a way to create my css files from my less files using web essentials or something of the sort. When create a new less file it will create the css to match, however on some of my older files I removed the css files permanently and I am looking to readd them.
grunt-contrib-less is a great solution for continuously converting LESS to CSS, as is assemble-less (I'm a maintainer of the latter).
So I was able to answer my own problem. When using VS2012 Web Essentials your .less file will not compile and create the matching .css and .min.css if errors exist. My errors were occurring because some of my variables were not recognized due to the fact that I wasn't dragging in the #import of the my .less file that contained these variables. I took a quick look at the libraries you mentioned and they did look pretty cool. Thanks for the answer.
It's important to say that if you installed the Web Essentials plug-in you must restart the Visual Studio, otherwise the .min.css and .css will not be generated, either.