So I'm using Codekit to compile LESS CSS on my local server. Now I need to transfer the files to my live server.
My question is, do I need to upload all the .less files? Or can I just upload the minified css file?
What is the best practice here?
If you don't plan on editing anything on your live server (which you shouldn't anyway), you only need to upload the compiled .css file; the compiled CSS is completely independent of the source LESS.
It is better to upload CSS files.
Firstly, LESS might not be compatible for all browsers and secondly, CSS is your output of LESS file will take up some time(minimal but why to force on client) to compile it on run time.
I am deploying files to a server from more than one machine, so I tend to upload (in my case) scss files (although less files are essentially similar) and then I can pull them down to a separate machine for editing. But the pages only refer to the css files.
As a minimum you only need to upload the compiled css file(s).
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.
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.
I'm considering using LESS for CSS development with server (or development) side processing, but I can't decide if I should keep the generated CSS files in version control. There are plenty of solutions with hooks, but this adds software dependencies to the server. A hook could just be added locally so staging and production areas on the web would get the same files. So, the question is:
Should generated CSS files be included in version control or not? Please keep in mind that some frameworks require a CSS file to exist for a particular reason (i.e. WordPress themes require a style.css file in order to be recognized).
When I say 'considering using LESS', I mean it becomes a requirement. New developers would not have the option use vanilla CSS after the choice is in favor of LESS.
Checking in derived artifacts is almost always sub-optimal.
I vote no to checking in the .css. It's only a matter of time until one of your peers or successors checks in an edit to the .css and not the .less. Then when you change the .less the prior change is lost.
You've pretty much answered your own question. It depends on how you deploy your website.
If the server is just going to pull directly from the Git repository:
1) It needs to have software installed to generate CSS from LESS.
2) or you need to include the CSS files in the repository.
If you're not pulling straight from the repository on your web server, you could have a build script that pulls from git, generates CSS, and then transfers the content to the web server(s), possibly excluding unnecessary files from the transfer.
In my opinion, Git should be used to keep all of the source for a project, and none of the "derived artifacts" (as mentioned by #thekbb). Developers need to have all tools installed to generate those derived artifacts during development and test. For deployment to test and production servers, an automated build server should take the source and create just the files needed for distribution.
In the case of software development, you'd have a Makefile with .C and .H files (for example) in your Git repository. Developers and the build server have a compiler installed that will create an executable or compiled library. When the files are packaged for distribution, the source code is not a part of the archive.
For web development, you have source files like original graphics, HTML templates and LESS files. Developers and the build server can run scripts to generate the site assets (CSS from LESS files, static HTML pages from templates, flattened images in multiple sizes/formats, etc.) When the build server deploys new builds, it copies just the files needed by the server, excluding the source graphics, templates and LESS files.
If there are people that need to review the site content, they should do it on a staging server. If that's not possible, the automated build server can create a ZIP file on an internal server that they can download for review.
Should generated CSS files be included in version control or not?
In theory they should not, but for practicality, I do usually checks in the generated css file. The reason is that it simplifies deployment since I do deployment using git; I would not need to have a less compiler installed on the server and usually not even on the machine I'm deploying from (as opposed to the machine where I'm developing on). Doing this could be useful if you have separate developer and deployer, but can sometimes also be useful even if you're deploying yourself.
Now, there are drawbacks on doing this:
You can't use git add --patch (or you really need to be very careful when doing so)
You should not modify the .css directly; instead I usually use a secondary .css file to do minor modifications without modifying the primary .less or .css file. You can also compile .less file straight into a minified css, to make it less tempting to modify the generated css.
Developers have to set up their machine to use automatic recompile tool (like SimpLess or Less.app), so the .css file is updated as soon as they save to the .less file. Without automation, you'll run into risk of the css not matching the checked-in less file.
I would not do the same when compiling from .C and .H files though, because the generated binary for those are platform specific, and also .less/.css file is usually a very small part of a larger web project so the space overhead of the additional file is small.
Good question. If you can absolutely guarantee that the CSS file gets updated when the LESS gets updated then perhaps yes - as per #Scott Simpson's comment. I suspect that this would be difficult to guarantee and what happens when the new developer get's a copy of CSS the day when they are out of sync? Also, of course, and I hadn't originally thought of this, what happens if the new developer then makes updates to the CSS file rather than the LESS?? If the CSS has to be built and isn't part of archive I can see less problems.
I would say yes -- because what happens if you want to add a developer to your workflow and they don't want or need to build .Less? It would be helpful for them to have access to only the generated file.
I want to use LessCSS for some of its benefits, but I don't want the user to have to download the less.js file or have it do any processing client side - I don't even want to have LessCSS working on my webserver. I'd like to write some Less, push it through LessCSS and then upload the resulting CSS file to the webserver.
Ideally I'd like LessCSS to process the Less file as when I save it in NetBeans and automagically pop out a css file.
Any ideas where to start?
Have a look at my blog entry (http://blog.nickdamoulakis.com/2012/04/php-less-css-and-cssjs-minify.html) where I list and describe a method I use.
Basically, I have a tab open in my browser that points to my compile.php.
Whenever I want to 'compile' files, I just press F5 and it compiles JS-->MIN.JS, LESS-->CSS and CSS-->MIN.CSS.
An INI file specifies which directories to process.
It is not a fully automated process but it works for what I need it to do.
I hope it is of use to you.
Check out SimpLESS. It's a standalone application, but it will monitor a folder for changes in .LESS files and auto compile them into CSS.