broccoli-less
broccoli-less copied to clipboard
sindresorhus
@import won't work correctly
:+1: 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'
});
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.
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.
@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 :)
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.
do you want to change this package to be n-to-one
Yes, just haven't had the time. Help welcome :)