Using the less's @import statement

[mdedetrich]

I am not sure if I am doing something ridiculously stupid, but it appears that less's @import and @import-once statements are not working with version 0.5 of sbt-less plugin

Assuming I have a flat directory called less with my build.sbt looking as follows

seq(lessSettings : _*)

(sourceDirectory in (Compile, LessKeys.less)) <<= (sourceDirectory in Compile)(_ / "less")

(resourceManaged in (Compile, LessKeys.less)) <<= (resourceManaged in (Compile, LessKeys.less))(_ / "css")

(resourceGenerators in Compile) <+= (LessKeys.less in Compile)

(compile in Compile) <<= compile in Compile dependsOn (LessKeys.less in Compile)

(LessKeys.prettyPrint in (Compile, LessKeys.less)) := true

(webappResources in Compile) <+= (resourceManaged in Compile)(_ / "css")

Assuming I have 2 files within the less folder, a.less and b.less, if a.less simply contains the following

@import "b";

It fails with
could not unshadow /Users/mdedetrich/scala/test/src/main/less/b

Using @import-once instead of @import I get
JavaException: java.io.FileNotFoundException: /Users/mdedetrich/scala/test/b.less (No such file or directory)

Obviously the files compile fine if there is no @import or @import-once

[davegurnell]

I can think of two potential issues:

• You'll need to add the .less or .css filename extensions to your @import statements.
• I haven't used @import-once before, so that probably won't work.

Hope this helps,

Dave

[mdedetrich]

Ok, adding the .less extension seems to work (even though technically speaking, the .less extension isn't required), however @import-once is meant to work (in fact, its pretty much required to work in projects of a non trivial size else it blows out the size of the CSS file)

[davegurnell]

We should definitely support missing filename extensions. Am I right in
thinking that the correct semantics are to assume a ".less" filename
extension if none is given? Or does the plugin have to search for ".css"
files of the same name as well?

@import-once syntax is a new addition to LESS. I totally agree with you
about the bizarre code-duplicating semantics of @import. We should support
the @import-once syntax for compatibility purposes. Note, however, that due
to some quirks of history, SBT-LESS actually already gives @import
statements the same semantics as @import-once.

Reasoning follows:

• when I first wrote SBT-LESS, @import-once didn't exist;
• like you, I work on big projects - @import statements produce lots of
  extraneous CSS
  (I assumed this behaviour was a bug);
• SBT-LESS supports features such as templating and search paths that mean
  we can't
  simply feed the raw LESS files to the LESS compiler. We have to inline
  everything
  ourselves.

SBT-LESS scans the dependencies in your LESS files in Scala. It templates
every file, inlines them all into one LESS file (using @import-once
semantics), and feeds the whole thing to the LESS compiler. Hence we bypass
the normal behaviour of @import.

There is a case to be made that we should support the proper behaviour of
@import. If enough people ask for it, or if someone submits a PR, I'm happy
to work on it.

Dave

On 24 July 2013 22:51, mdedetrich [email protected] wrote:

Ok, adding the .less extension seems to work (even though technically
speaking, the .less extension isn't required), however @import-once is
meant to work (in fact, its pretty much required to work in projects of a
non trivial size else it blows out the size of the CSS file)

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/33#issuecomment-21519038
.

[mdedetrich]

We should definitely support missing filename extensions. Am I right in
thinking that the correct semantics are to assume a ".less" filename
extension if none is given? Or does the plugin have to search for ".css"
files of the same name as well?

I'm not sure if thats right in how less is technically defined, but its definitely the most practical way to implement it in my opinion

@import-once syntax is a new addition to LESS. I totally agree with you
about the bizarre code-duplicating semantics of @import. We should support
the @import-once syntax for compatibility purposes. Note, however, that due
to some quirks of history, SBT-LESS actually already gives @import
statements the same semantics as @import-once.

I actually noticed this myself. I used @import in places that would cause duplication, and it didn't duplicate (at which point I was wtf....).

• when I first wrote SBT-LESS, @import-once didn't exist;

Yup, and due to this I stopped using less entirely. I used Play 2.0 (which had its own less processor), and that version didn't have @import-once. Lets just say that the code bloat was massive

• like you, I work on big projects - @import statements produce lots of
  extraneous CSS
  (I assumed this behaviour was a bug);

I also assumed it was a bug, and then I read the less mailing lists (at the time), and I read that the behavior was intentional. It is literally an "include" in every sense of the word, it places the code.

• SBT-LESS supports features such as templating and search paths that mean
  we can't
  simply feed the raw LESS files to the LESS compiler. We have to inline
  everything
  ourselves.

Yup, and this does sound like it would complicate matters

There is a case to be made that we should support the proper behaviour of
@import. If enough people ask for it, or if someone submits a PR, I'm happy
to work on it.

Personally, I think it should so its consistent with how LESS is meant to work. I wouldn't put it at complete top priority, but it it something that should be done. I was about to move off Scalatra (and SBT-LESS) because @import-once didn't exist (until I realized that @import is essentially @import-once), so I guess from the POV of giving a false impression, it should be changed

[davegurnell]

@import-once was deprecated in Less CSS v1.4, so I opted to upgrade the version of Less rather than supporting it here. Note that Less CSS 1.5 will add inline import syntax for CSS files:

@import (inline) "foo.css";

I'll look at this for a milestone release of 0.7.