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.
Related
I'm running JetBrains ReSharper 8.2 on a project that uses SASS for styling.
I compile my seperate scss files into one file "common.css". This file is not included in the project, but gets compiled on build on the server (grunt + compass takes care of this).
I don't want to include this file, but only my SCSS files in the project. This however causes ReSharper to report a lot of errors ("Unknown CSS class"...) in my views because the file isn't included.
Is there a workaround for this (without disabling css errors in settings)?
I've tried the "ReSharper.ExternalCode" extension (https://resharper-plugins.jetbrains.com/packages/ReSharper.ExternalCode), but without any luck.
Sadly, there isn't a workaround for this. ReSharper doesn't know about SCSS files, and doesn't know anything about files that aren't included in the project, so it can only assume the CSS classes are undefined.
The external code plugin should work and allow ReSharper to process the resulting css file. However, I'm not sure how flexible it is - I think it needs everything to be configured before the solution is opened. That is, it only tells ReSharper about the generated file when the solution is being opened. Configuring things while a solution is open probably won't be reflected immediately (but I haven't tried it). Similarly, it doesn't notify ReSharper of changes to the file, and I don't think that ReSharper sets up any monitoring. So if the file isn't available when the solution opens, or changes while it's open, ReSharper won't have correct information. I'd try and configure it, close the solution and reopen.
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.
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.
if you're familiar with Liferay you'll know that when you make an itsy-bitsy change to a css file you shall rebuild the theme and redeploy it.
As for redeploying I made a symlink (mind you I'm on Windows: for the curious creating a symlink on Vista is just a matter of issuing mklink /d dir1 dir2).
But what about rebuilding the stuff with maven? I'd rather skip that step. Basically what it does is combyining and packing all CSS in one everything_packed.css. Is there a sort of config variable to tell liferay just to include the raw files and skip redeployment alltogether?
Thanks
Guys I found the solution myself.
You should have a file called portal-ext.properties file in
$TOMCAT_DIR/webapps/ROOT/WEB-INFO/classes
Or more specifically for my win setup in
C:\liferay\webapps\ROOT\WEB-INF\classes
The file would hold the value
theme.css.fast.load=false
This will prevent liferay to be looking for the everything_packed.css and so you're free to modify your stuff without rebuilding and CTRL-R to refresh the page and see the changes.
Just for completeness, as this question is somewhat old and the problem already solved: There's a lot more along these lines, e.g. javascript, layouts etc. that can be used uncached. This is documented in either the Liferay Wiki (as Developler Mode) or the Development Guide, available from the documentation site (though currently it's not there for the last version - if it's still not there when you're reading it, look for it (PDF) in the older versions.
It's advisable to use these settings only in development, not in production, as putting all css and javascript in as few files as possible results in a huge performance impact.
to include all those settings, just can also just add the following line into your portal-ext.properties file:
include-and-override=portal-developer.properties
this will include all the developer specific settings, and when you want to remove them, you can just comment out this line.
you can edit the css files of your theme from Webapps{your theme}\css
And can see the changes directly.
You can edit almost every file which doesn't require compilation.like .jsp files but not .java files