Crunching / Compiling LESS - css

I have tried both SimpLESS and Crunchapp both return the same error.
I am trying to compile this bootswatch http://bootswatch.com/cyborg/ and when I do I get the following error.
Compiler Errors
variable #grayLight is undefined (Line: 17)
Does anyone know what I am doing wrong?

You must define the variable in the same file where you using it:
#grayLight: #e7e7e7;
Or if it defined in another .less file you must import that to see the variable in another file:
#import "mixins.less";

You have to asign the variable value first, for example:
#grayLight: #ffffff;
It's exactly as error said, you use variable that is undefined.
Then you can call this variable at any place in code. If it happens you defined it earlier, check if names are equal (letterCase as well).

Related

The #use feature of Sass

First of all, I hope someone can actually understand this rambling question because I'm struggling to even word what I mean in a coherent way, but here goes:
I don't know why I'm struggling so much to figure this out, but I've been using #import with SCSS for a while now and feel I have my head around it fairly well, but now I want to use the #use rule since the phasing out of #import is a thing. And I can't find any videos or any real articles explaining how to use it properly.
The problem I'm having is I can't get my head around how to actually use it, I feel like I get the basic idea, and how to use the modules in each partial (I think..), but I feel like I don't understand how to actually get all of the partials into a main .scss file to be compiled into css.. This is hard to explain.. I just feel like I would still need to #import at least the files that have #use inside them into a main file for it to be compiled.. I'm guessing this obviously isn't the case, but otherwise I can't work it out.. Do I just #use all the files I want imported into the main file or..?
If anyone could shed some light on this for me, I would be really grateful.
Thanks
The new rules #use/#forward and the remove from #import are indeed a really big impact to SASS. It leads to a complete new form to write sass. A try to make an easy explanation for the beginning to use the new technique:
(1) #use works similar to #import. It adds the code from a (config- or partial-)file or a module to your stylesheet.
(2) The difference is: SASS changes the scope of variables/mixins/functions from global (all imported files = one scope) to local files (variables are only valid in the actual file). If you need to use variables/mixins/functions from another (config- or partial-)file you need to 'include' them to the actual file first.
That means for your project(*):
//file ###> _config.scss
$columnWidth: 50%;
$projectColors: (
primary: red,
secondary: blue,
);
//file ###> _functions.scss
#use 'config' as * // --> to use config vars (here: without namespace)
#function getColor( $name ){
$color: map-get($projectColors, $name);
#return $color;
}
//file ###> _partial.scss
#use 'config' as * // --> use config vars (here: without namespace)
#use 'functions' as * // --> use functions (here: without namespace)
.class {
width: $width;
color: getColor( primary );
}
//file ###> myStylesheet.scss
// no need to #use 'config' or 'functions'
// as they are not direct needed in this file
#use 'partial' //--> write the css
---
( * ) Including files without using a namespace is a special case to make the example more easy. Normaly you will include variables/mixins/functions to a separated namespace and call them by namespace.$variable or namespace.mixin. And there are techniques to move special settings to a #used file as well so you can move variable settings to the project. Please have a look to official and excelent description: https://sass-lang.com/documentation/at-rules/use
NOTES:
(1) As it is heavily discussed: Yes. This is INDEED the intended new way to work with SASS. (https://github.com/sass/sass/issues/2750)
(2) Very interesting: The actual brandnew version from Bootstrap has moved to the new Sass Version. But as I have seen Bootstrap does not use that new feature #use and still works with #import. That may have reasons ... and it seems not to easy to change the technique.
(3) Also it seems to be a little bit complicated there are some advantages comming with that new technique. Using separate namespaces make it much mor easier to work with external modules without causing name conflicts.

How to display the error path of where the custom function is used?

If I use a built-in Sass function that returns an error, it will display the path of where it is used.
Using a built-in Sass function:
Code from _test.scss.
.foo {
color: darken(blue, s);
}
Will result in:
error _test.scss (Line 2: $amount: "s" is not a number for `darken')
Now, if I use a custom function that returns an error, it will display the path of where it is defined instead of where it is used.
Using a custom function:
Code from _test.scss.
.foo {
color: example(string);
}
Code from _functions.scss.
#function example($string) {
#error 'error message';
}
Will result in:
error core/utils/_functions.scss (Line 2: error message)
Is there any solution for solving this "issue"?
Your examples are similar only visually, underlying logic is completely different:
For built-in function Sass throws error by itself because code is not valid from Sass point of view.
Into second example you're throwing error because code is not valid from your point of view. Code itself if valid from Sass point of view in this case.
In both cases Sass displays same information about error location - a point into your codebase where error occurs. But in a case of your own, intentional error throwing actual point where error occurs actually matches a place where you're generating this error - exactly at a place where you have your #error directive. So there is no mistake into Sass behavior because it knows nothing about reasons why did you decide to throw an error.
You can always analyze stack trace that is displayed (at least by node-sass) along with error message to decide where did you get to point of error from. You can also use #debug to display context that may be useful for error analysis.

`Unrecognized input` error with LESS guarded mixin

In my LESS project I am having issues getting my guarded mixins working with variables that I declared in another file. Here is the code I am working with:
_defaults.less (contains all of my variables)
//------------------------------------//
// #INCLUDE
//------------------------------------//
// Set whatever components you want included
// in your project to `true` and any components
// you do not wish to be included to `false`
// Base
#use-main: true;
_main.less (just a random partial in my project)
.main(#boolean) when (#boolean = true) {
// Styles go here
}
// Execute mixin
.main(#use-main);
style.less (imports all of my partials)
//------------------------------------//
// #IMPORTS
//------------------------------------//
// Base styles
#import "base/_main.less";
This is how my project is structured (for around 20 partials that are then imported into the style.less file).
Whenever I try to compile my project, I get this error:
Unrecognised input
c:\Users\Keenan\Documents\GitHub\concise.css-less\less\base_main.less line 1
c:\Users\Keenan\Documents\GitHub\concise.css-less\less\concise.less
The code you pasted is correct. In fact you are misled by lessc error message. It refers to the #main block. It seems the issue you are facing is related to your project Concise.css-less and more precisely this line.
#if #global-border-box == true {
// [...]
}
This is not the proper syntax for if statements in less. See question:
How to use if statements in LESS
It seems you are converting a project from stylus to less. I would suggest cutting large chunks of files that fail to import to find out, through bisection, the lines that less doesn't recognize. Alternatively, you could comment the top mixins guards that are used here to include this or that part of the css, and that confuse less for error reporting.
For example, if you comment the first and last lines of file _lists.less:
//.lists(#boolean) when (#boolean = true) {
[...]
//.lists(#use-lists);
lessc will report the error near the proper line (actually it's > on line 111 that it doesn't like):
ParseError: Unrecognised input in concise.css-less/less/base/_lists.less on line 109, column 9:
108 .breakpoint(small) {
109 dl.dl-horizontal {
110 overflow: hidden;

Why is mix() not working with my colors in LESSC?

My less file piggy-backs on to the end of the Twitter Bootstrap files (so things like #white are defined already. Here is my less code:
#columnSortScreen: #99f;
// the color used
#columnSort: mix( #white, #columnSortScreen );
When compiled, I get the following error (everything underlined by carets is highlighted):
non_object_property_loadError: error evaluating function `mix`: Cannot read property 'value' of undefined in /Users/cmv/Sites/...../tablesorter.less:12:14
11 // the color used
12 #columnSort: mix( #white, #columnSortScreen );
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
What am I doing wrong? Lessc is version 1.3.0.
Thanks!
I had the exact same error.
Did some digging and found this:
The docs for mix are missing the third parameter.
Try:
#fallback-color: mix(#from-color, #to-color, 50%);
Note the third parameter. This solved it in my case, does this fix it for you?

SASS: Set variable at compile time

Is it possible to set a sass variable at compile time? I basically want to do this:
$color: red !default;
div#head {
background-color: $color;
}
When I compile to css I want to set $color to "blue" (preferably from the command line). Has anyone been able to do this?
Thanks,
Chris
I found this at their FAQ http://sass-lang.com/docs/yardoc/file.FAQ.html
If you just want to pass some variables to the CSS every time it gets compiled, like using --watch, you can use Sass functions to define Ruby scripts to even query a database. But the code is going to be compiled only once, and served statically.
But if you need to recompile it at every request with different options,
you can use Sass::Engine to render the code, using the :custom option
to pass in data that can be accessed from your Sass functions
Seems like it's not recommended, though. Probably for performance reasons.
An alternate of command line options is to create other files assigning values to variables.
Assume that your code above is in a file named 'style.scss'.
To set $color to "blue", create a file such as:
$color: blue;
#import "style";
and name it to 'blue.scss' for example.
Then compile it with below.
sass blue.scss:style.css
When you want to assign another value to the variable, make another file named "green.scss" like:
$color: green;
#import "style";
Then compile it with
sass green.scss:anotherstyle.css
It is bothering somewhat but enables to decide values of variables at compile time.

Resources