So, the compilation of (_)file.scss files to *.css files works great. Just one thing: For each file the watcher encounters, it creates a cache file. It does this right next to the file being compiled, e.g.:
_partial.scss
style.scss
Generates:
/.sass-cache/C0mpl1cat3dh4sh/_partial.scss
/.sass-cache/C0mpl1cat3dh4sh/style.scss
style.css
Of course I could simple delete the files when they're generated. Could add them to .gitignore. But these are work-arounds.
How to disable the generation of these cache files?
In the options I could not find an option to do this when searching "cache", "file watcher" or "watch".
Extra info:
Running 2018.3.3, built 9th January 2019
Have not seen this before, though haven't mucked around with scss in a while (2 - 3 months), so not sure if it's a recent addition to PhpStorm
Launch a terminal and find out the command-line switches offered by your SASS implementation, typically with:
sass --help
You appear to be using old Ruby SASS. If I recall correctly, the switch was:
--no-cache
Add it to the Arguments input box and you should be done.
As already mentioned, Ruby SASS is no longer being developed so it can be a good moment to switch to Dart SASS, which does not have any cache to care about.
Ruby sass is deprecated already for a while, development is moved towards Dart implementation while LibSass is also actual implementation, but may step behind Dart implementation in some aspects. LibSass have plenty of integrations for various languages, please refer documentation by link above.
Both of these implementations are much faster then Ruby sass and doesn't produce any additional cache directories.
I'm having trouble getting Babel to work on my current installation of Webstorm 11 on Windows. For some background I'm currently using Webstorm to do Angular development with a Microsoft MVC project (constraints of the project). For the most part it has gone well but I've wanted to move to es2015. I'm already using node package manager and the LESS transpiler with no issues. In trying to figure out what to install I went through a number of packages:
Babel
Babel-cli
Grunt-cli
Grunt-babel
Babel-preset-es2015
It this stage I'm okay with not using grunt; I just want to get a file to transpile before moving on to that. I actually have Webstorm thinking the file watcher is there but it doesn't actually transpile the code. I figured out es2015 was no longer on by default so I installed the last preset and it totally through my machine into a grind of processing tasks that maxes out my machine and only ended with an exception looking trying to for path under my project. That path is indeed valid. If I re-enable the file watcher it will max out my machine again.
All these seems pretty abnormal to me given I just want to enable the damn es2015 processing. Somewhere I'm obviously doing something wrong so I'm hoping someone can give me some input in what I truly to setup Babel properly.
Thanks!
Sieg
I'm currently using Web Essentials 2013 update 4 to provide support for compiling .scss files in Visual Studio.
The tool has worked fine for me in the past however I have just created a new .scss file and have copied the bootstrap un-minified css into this new file.
Upon saving, the compilation window on the right hand side of the screen fails to update or display the compiled css or any error messages. Meanwhile, the blue bar at the bottom of my Visual Studio screen is stuck on
Compiling 0 dependent file for bootstrap.scss
Usually I would expect a bootstrap.css file to be generated from this as well as a bootstrap.min.css file but this is not happening.
Does anyone have any ideas how I can restore this back to normal working conditions?
This was to do with the settings I had in my WebEssentials-Settings.json file. In version 3, the 'UseRubyRuntime' parameter needed to be marked as true to allow it to auto compile into the relevant files. Since version 4 this can be marked as false as WE now has a built in compiler which I believe may have been conflicting with the RubyRuntime version I was trying to use.
I had a similar problem, after installing Web Essentials 2013 Update 4 the .scss files started throwing errors like this to the output:
Something went wrong reaching: ...
SCSS: Site.scss compilation failed: The service failed to respond to this request
Possible cause: Syntax Error!
The only solution for me was this:
Uninstall Web Essentials
Delete %AppData%\Local\Microsoft\VisualStudio\12.0
Delete %AppData%\Roaming\Microsoft\VisualStudio\12.0
Repair VS 2013.4
Reinstall Web Essentials
Source: https://visualstudiogallery.msdn.microsoft.com/56633663-6799-41d7-9df7-0f2a504ca361/view/Discussions/1#15143
And a heads-up: If you import other .scss files, make sure they are in the correct location. When I updated Twitter.Bootstrap.Sass 3.3.3 via NuGet, the related .scss files were moved to a different folder and I had to update references. For example:
Before:
#import "../sass/bootstrap/_utilities.scss";
After:
#import "../stylesheets/bootstrap/_utilities.scss";
I had the same problem, and spent some time uninstalling and re-installing Web Essentials. I tried deleting the parts of AppData that seemed to be related to Web Essential, all with no success at compiling the scss file.
So I created a new .scss with minimal content, that compiled. Then I started copying over pieces from the failing one. After a couple of copies, the new one failed too. I was able to zero in on the failure.
It was caused by this line:
$highlightcolor: #67a0f;
Do you see the problem? the hex color code is missing a digit. it should have been 67a0f5. Fixing this fixed the problem with the original file.
I had gone over the file looking for syntax errors, but didn't spot the short color def.
I hope this saves someone some time and frustration.
I had the same problem; in order to help diagnose it I created a minimal .scss file with dummy CSS rules - it generated the same error.
Then I went to my long-time tested and fully working legacy .scss file - it generated the same error. Something is wrong here, I thought.
After tinkering with the issue for a while, somehow it got fixed by closing Visual Studio, reloading and reopening the solution.
Referencing the changelog, as of 2.5 for update 4 of Web Essentials:
Removed all node.js based tools â—¦Sass/LESS compilers
JSHint/JSCS
linters CSS AutoPrefixer Handlebars compiler SweetJS/LiveScript
compilers
http://vswebessentials.com/changelog
So my understanding is, that it no longer compiles.
I am having the same problem and have eliminated actual syntax errors and incorrect path references. I have found two things out about this.
This happens when there is a file that only specifies variables and
has no actual scss or css markup. This is more of a hack as you
may have to put unwanted css in a variables file.
Turning off Autoprefixer will resolve the issue entirely, but at the cost of not using this feature.
I had this problem and determined that when I was running a Compile All SASS Files, the plugin was trying to compile files found in the /obj directory of the project which failed, and consequently caused subsequent compilation to fail. Deleting the /obj directory and restarting VS fixed the issue.
I had a similar issue and turn out to be a reference to a SASS variable before it was declared. There were no warnings or errors. Once I move the reference to the right place it all worked fine.
Going off of what others have said about Web Essentials. Looking at the change log, it states that for versions 2013 update 4 and up (meaning version 2015 as well),
Important! Bundling, minification and compilation of LESS, Sass and
CoffeeScript is not longer part of Web Essentials 2015. Install the
new extensions Bundler & Minifier and Web Compiler instead. Also, see
this list of other web development extensions that might be of
interest to you.
I found this neat little extension for visual studio, that compiles the SCSS file(s) on save into a CSS file (along with minification for that file).
You can get it here.
The guy that created this extension also talks about the Web Essential issue as well, found here.
I have a relatively big sass project with quite a few sprites. When I have compass watch running and make a change, the project takes a few seconds to compile because checking the sprites takes a long time. The sprites are NOT actually getting overridden or anything (unless of course I change the images) but just the process of checking each image takes a while. Is there a way to run compass watch while ignoring sprites just to speed things up? Then if I want to change sprites I can just manually compile.
I've been searching for a solution to this as well. A not great (but working solution) can be found here: Codekit Compass vs Less compilation when spriting
Basically I have a sprites file allSprites.sass which creates allSprites.css. I then put that into _sprites.scss and import that into my main.sass file.
If I could automate moving the allSprites.css into the _sprites.scss on change of the allSprites.sass file my life would be complete =)
I'm using Compass Sprite helpers in a project which works great. However the generation of the sprite adds quite a few seconds to the project compile time and most of the time I do not need it regenerated.
Is there a way to turn off the sprite generation and get compass to use the last generated file?
I'm using CodeKit and I'll be easily confused by much talk of command line / Ruby!
I've just tried it, and for me Compass does not recompile my sprites unless i modify the contents of the sprites folder:
$ compass compile
unchanged images/sexy-sce786a2ec5.png
overwrite stylesheets/screen.css
Try compiling your project with the compass command line tool instead of CodeKit. If it works out, please check that CodeKit uses Compass to compile your project and not vanilla SASS.
It looks like a CodeKit issue which is getting fixed:
https://github.com/bdkjones/CodeKit/issues/297
Until then I am using a workaround detailed here.
It looks as if compass compile with no other arguments (as per Andrey 'lolmaus's answer) does not cause this, but if there are any arguments at all it sets the :force option to true, and one of the consequences of that is that sprites are forcibly recreated.
That seems like crazy behaviour?
For the moment I've edited lib/compass/commands/update_project.rb (specifically, in my case, ~/.rvm/gems/ruby-1.9.3-p429/gems/compass-0.12.4/lib/compass/commands/update_project.rb) and commented out the parser.options[:force] = true line in the parse_arguments! function at the end of that file.
(note the unless arguments.empty? condition)
That seems to have disabled sprite generation entirely (i.e. even when you need it), but I can enable it manually with compass compile --force ...
That's certainly good enough for me.