I want to declare a variable with the path to the library:
#libPath: "any/path/to/lib";
And use it in #import. Something like this:
#import "#{libPath}/file.less";
And I see the result after processing:
#import url("#{libPath}/file.less");
No such possibility or am I doing something wrong?
Thanks.
FWIW this is a bug in less.js that’s been discussed for way over a year now. There are at least two attempts to fix this but one requires large changes to the public API and has consequently been rejected. The other approach only works partially.
On the other hand, lessphp supports this without problem now; I have no idea whether dotless does.
It isn't supported in less.js or dotless so I assume less PHP is the same. It might not be hard to add, why don't you add a feature request.
Also what is the problem you are trying to solve? Maybe it can be solved a better way.
Related
How can I connect these 2 partial folders (variables and base) with my main.scss?
Don't refer me to any video or such, I have watched and tried for the past 3-4 days, nothing working!
Greatly appreciate your help fixing this if you're knowledgeable with sass since I'm not!
That's what the #use rule is for! Adding #use "abstracts/variables"; and #use "base/base"; to your main.scss adds their CSS to yours, and makes their variables, functions, and mixins available with variables. and base. prefixes. You can add as * to the rule (e.g. #use "base/base" as *;) to make them available without prefixes.
This assumes your Sass tool is based on Dart Sass, which most are nowadays. Old tools might be using LibSass, which only supports #import; I recommend using only Dart Sass-based tools whenever possible.
I'm moving from Grunt to Gulp and noticed that gulp-sass does not include the contents of files referenced by #import "reset.css" statements. Instead, it normalizes the url reference, as #import url(reset.css). My intention is to have a single CSS reference on my index.html, that would be the concatenation of my CSS dependencies.
It's a simple read-file-and-output-contents operation, but I bet this is already implemented and I just don't know where to find it -- I'm still new on this ecosystem and would not like to spend time reinventing the wheel.
EDIT: the selected answer for this related question uses gulp-minify-css, instead of gulp-sass. Exchanging them could be a short-term solution, but I'd prefer to avoid my new build system to rely on unstable plugins. Moreover, I actually have plans to use scss, so I'd be back to having to deal with gulp-sass again. Thanks for the suggestion, though.
#import should actually include the contents of the file, not make a reference to it. Sounds like maybe the transpiling of the SCSS to CSS isn't working properly.
I have an issue with sass compilation.
When I have a project with a partial _partial.scss and have it imported in multiple partial files (because it contains color variables) it will end up in the compiled css multiple times!
This is ugly because the same rule will 'overrule' itself multiple times which makes debugging info (chromium dev tools / firebug) rather unreadable.
I presume there is a solution for all this. I just can't find anything on the issue, anywhere.
The solution is to either not include the same file multiple times or don't have any code that directly outputs CSS in the file you're planning on including more than once. If your variables were in a file by themselves, they could be safely included anywhere you'd like without selector duplication.
Maybe this #mixin helps you: https://github.com/wilsonpage/sass-import-once.
Have a look at the example and note how the reset is only included once in the final CSS.
It seems that just for this, sass (and thus, scss) now have #use instead of #import. From the #use documentation (emphasis is mine):
The simplest #use rule is written #use "", which loads the module at the given URL. Any styles loaded this way will be included exactly once in the compiled CSS output, no matter how many times those styles are loaded.
Sass also discourages further use of #import:
The Sass team discourages the continued use of the #import rule. Sass will gradually phase it out over the next few years, and eventually remove it from the language entirely. Prefer the #use rule instead.
Any projects having this problem could try running the module migrator tool and check if the problem is resolved.
Is there any way in LESS to render the original LESS File + Line Number in the rendered CSS?
Just as Middleman does with SASS... (I'm not sure if it is a SASS or a Middleman feature)
I'm not familiar with Middleman, but the GitHub page for FireLess (inspired by FireSass, I guess) suggests that it would show the Less line number in Firebug, rather than the compiled CSS line number.
I have no idea why the selected answer was chosen to be correct - it relates to a different build of LESS built for the .NET framework, not simply LESS itself.
Anyhow, yes, LESS does support this. It's not particularly well documented, but if you compile using the --line-numbers=[comments|mediaquery|all] flag, it will compile your CSS with the debug info spec SASS established.
If you're using Grunt, and grunt-contrib-less, you can use the dropLineNumbers option (really strange choice of name, imho). I typically set mine to all.
There is now an option in dotless to output this information as per sass does. the flag is "debug". It will be included in the next release - https://github.com/dotless/dotless/issues/186
I am attempting to use lesscss to build a templating system where each template has 3 or 4 alternative colour schemes.
So for example, I could have a red.less stylesheet that looks like this:
#main_colour: #ff0000;
#import 'main.less';
So, I only have one main.less stylesheet to maintain which contains all the main styles, and uses the variables set for colour codes. I can then create a seperate colour.less file for each colour scheme.
Only problem is when I try to do this I get a Less::VariableNameError which indicates that LESS is parsing the #imports BEFORE it parses the variables.
Is there a workaround to this or any other way to achieve the same end result?
In reference to your tweet, yes, this would work as you expect in Sass. I'm actually kind of surprised that it doesn't work in Less.
I guess the Less guys wanted to keep the .Less file atomic and independent of external environmental settings. This was what I assumed, but I also didn't like it so our .NET port http://www.dotlesscss.com will allow you to do this by default.
Its not a big change to do in the original Less ruby version and if you fancy tinkering with the source I can point you in the right direction.
Out of interest, without been traitorous to the Less team I quite like the SASS syntax now and there are additional things such as conditional statements and loops that you cant (yet) do with Less.
#nex3 - you guys should stop competing and just work together.
Seems like this isn't a problem any more, or at least not for me using "dotless" for .net?
Seems to work fine now with latest LESS.