Differences to grunt-contrib-less

[Arkkimaagi]

Since Grunt has already plenty of LESS support, I think it would be a good idea to elaborate what assemble-less does better than it in the README.md.

[jonschlinkert]

I'm on the core team for LESS. Seems like the README is quite lengthy and detail in terms of differences, as is code documentation. Can you give me some detail?

[jonschlinkert]

Read this section (and the line directly below this link): https://github.com/assemble/assemble-less#task-options

Those options are unique to this task. I'm happy to add more docs but please specify what kind of documentation you'd like to see, or why elaboration beyond what is in the README is necessary.

[Arkkimaagi]

So, could one say that Assemble-less is a bit closer to the source of LESS in a way?

Please do not get me wrong, I stumbled upon Assemble-less as I was browsing what else is there besides Assemble/Assemble. I'm really happy what I've found with Assemble-repositories, so I wanted to see more. I also like LESS and was wondering if I should switch over to Assemble-less from grunt-contrib-less. So I started wondering what are the biggest differences between those two. So I thought, maybe someone else is wondering the same thing and more people might prefer Assemble-less if they'd see a list of benefits over the alternatives.

Other than that, the documentation seems quite excellent. Good job! :)

[jonschlinkert]

No worries, grunt-contrib-less is excellent, and the codebase will certainly be more stable since we're adding "experimental" features here.

So it depends on what you want. The reason I use assemble-less is that it's great for building components. For instance, if you use Bootstrap, you can use assemble-less to build each Bootstrap LESS component without adding @import statements for variables and mixins to each file.

You just add variables.less and mixins.less to the less property on the options.imports object, and then then bower install bootstrap to the "vendor" folder for example:

less: {
  options: {
    paths:   'vendor/bootstrap/less',
    imports: {
      less: ['mixins.less', 'variables.less']
    }
  },
  component: {
    src:  'vendor/bootstrap/less/alerts.less',
    dest: 'assets/css/alerts.css'        
  }
},

[jonschlinkert]

And if you haven't seen it, look at the @import (reference) feature that is coming in Less.js 1.5 ;-)

[Arkkimaagi]

Okay, this clarified things quite a lot.

I do in fact use bootstrap. But I do try to handle all the components within one css file as that way I have less files to transfer. Also after the initial load the main css should be cached.

However, I also see the benefit of your approach, as if there's a section of the site that uses components more heavily than others, compiling an extra css for that page containing the components could be really handy with assemble-less.

Also, it's cool to see LESS becoming smarter. :)

[jonschlinkert]

I do try to handle all the components within one css file as that way I have less files to transfer.

I think you might be overlooking a critical advantage of using the approach I mentioned (and assemble-less to compile). Compiling individual components is only advantageous for development or documentation, but everything gets concatenated into a single CSS file for production.

I was just using Bootstrap as an example, but the idea is that during initial development of a LESS component, you can isolate the styles to make them extremely simple to debug, and if you like using modular design patterns or conventions like OOCSS this is also a great way to ensure that your component "stays within its own boundaries". Of course, this is also advantageous when you're using the browser version of Less.js for development (since you should avoid using less.js in the browser for production)

I've had a long day lol... I still haven't had a chance to catch up on the issues you mentioned earlier. Sorry