@import won't work correctly

[sindresorhus]

Follow the lead of broccoli-sass when something happens there.

[jakswa]

👍 I had the same issue. Essentially, you can tell less to look in folders for @imports when the command is called but I don't believe broccoli will pick up on changes to those dependencies.

This is as close as I could get to making @import work. It will only watch the "top level" less files for changes, though:

  // put the "top level" less files in a folder by themselves
  // these files have `@import` lines inside them
  var cssSource = broccoli.makeTree('client/css/main');
  cssSource = bless(cssSource, {
    // put dependencies in a separate directory for the less command to search through
    paths: './client/css'
  });

[joliss]

Yes, we'll have a proper solution for that. It will allow you to pass input trees into LESS/Sass, and changes will be picked up correctly. Haven't had the time to get started on this, but it's high on my list.

[joliss]

Check out this implementation of broccoli-sass: https://github.com/joliss/broccoli-sass/blob/master/index.js I think you should be able to copy from it.

It currently doesn't come with caching. I'm assuming that sooner or later we'll have to add a caching wrapper around it. Getting the invalidation right without making spaghetti code is a bit tricky. Perhaps libsass is blazing-fast enough that we can do without caching, but clearly for LESS we'll need caching.

I shall write about caching for multi-file compilers like Sass or LESS at some point.

[gabrielgrant]

@joefiorini just pointed me here: in order to fix compilation in ember-cli, I just published a couple new broccoli plugins for compiling LESS and Stylus that are based (very) heavily on your broccoli-sass, @joliss

It looks like broccoli-less and broccoli-stylus are currently mapping input .less/.styl files one-to-one to output files, which is why tracking @imports doesn't work -- from what I gather, having that sort of a dependency tree to create a single output file isn't really what broccoli-filter is for (at the moment, at least).

I could see there being some valid use-cases for wanting this one-to-one mapping, but it seems like in general people will want the the n-to-one semantics. @sindresorhus do you want to change this package to be n-to-one, or just leave this as is, and have a separate package for when people need a dependency tree?

Either way, at least we'll now have working compilation in ember-cli :)

[joliss]

it seems like in general people will want the the n-to-one semantics

I (tentatively) agree, for what it's worth. I polled a bunch of people on Twitter a while back, and it seems that it's common to have many input Sass/LESS/... files, but only 1-4 ouput files.

When I looked into it with Sass, I saw that Rails by default compiles all the .scss files into .css, unless they start with an underscore ("partials"). But that seems like a legacy of the Rails asset pipeline and its assumption that files map 1:1ish. The grunt-sass plugin is less opinionated, it lets you do 1:1 and n:1. For broccoli-sass I stuck with specifying input files explicitly (n:1). I've in the past had issues in the Rails asset pipeline where it accidentally compiled a lot of unnecessary files, gobbling up CPU at deploy time; so compiling everything didn't seem like a great default.

[sindresorhus]

do you want to change this package to be n-to-one

Yes, just haven't had the time. Help welcome :)