config file - less.json

[kievechua]

Add config file less.json

{
  "options" : {
    "paths" : {
      "www/less/some.less" : "www/css/some.css"
    }
  }
}

so when I run less . it will compile based on the config
Just like yuidoc's yuidoc.json

[pronebird]

lessc www/less/some.less www/css/some.css is your config

[matthew-dean]

I actually think this idea is important, but I don't agree with the implementation. It's quite possible for two files in the same directory to have different configurations, or simply different output paths per file, and that's often true for my projects. For me, this is intuitively located in the root file that is being compiled. And I would construct it more like LESS / CSS, in a comment syntax. Like this:

/// options  {
///    cssOutput: "www/css/some.css";
///    minify: true;
///    ...etc
/// }

Something like this is essential for file-based editors, and of course useful for shared projects, or simply preserving settings when migrating without re-configuring.

UPDATE:

Oh, now I see what you did. You're putting in a map for every file. ...And that file could just be located in the same folder as the file you're compiling. Well, frig, that's probably a better idea than modification of the source file. But then... it could be more like...

{
  "options" : {
    "some.less" : {
       css: "../css/some.css",
       minify: true
    }
  }
}

That leaves the door open to future configuration options being added.

[ricardobeat]

Does this make sense considering that lessc doesn't even have a --watch option? It should either stand by itself or leave it to build tools, IMO.

[lukeapage]

as long as it just exposes the compiler functionality, I think its a good idea.. e.g. if we are just making less more configurable and flexible its good.. then the build tools can become more powerful :)

[matthew-dean]

This could be used to configure loading / debugging options in browser, or at compile time, or at load time of LESS files for editors. I actually need to do this anyway, but it would be nice to have an agreed-upon standard.

[jonschlinkert]

I agree with @agatronic, the build tools are limited in what they can do with LESS. Look at grunt-contrib-less https://github.com/gruntjs/grunt-contrib-less/ as a good use case. There are a few things I can think of that could be set as options to make builds more powerful:

  {
      options: {
      globals: ['assets/less/variables.less','assets/less/mixins.less'],
         src:  ['assets/less','node_modules/bootstrap/less'],
         dest: "assets/css",
       minify: false
      }
  }

[jonschlinkert]

in the spirit of just continuing the dialog around ways to accomplish this, so we can move toward the agreed-upon standard mentioned by @MatthewDL, here are a couple of suggestions for how less could leverage the less.json files for configuration. Whether it ends up exactly like this or not isn't material, I just want the flexibility afforded by these options.

In the examples I keep making use of "globals" (or whatever we want to label them), because I like the idea of not having to import those directly into each less file in order for it to compile separately. I thought of having objects for variables and mixins, but that doesn't make sense. The operative point is that it needs to be easier to have a separation of concerns in LESS files, without creating a big unmanageable mess. There may be other ways to accomplish this than what I've outlined, but I like this because it's clean and simple - especially if we can make the "globals" concept optional for projects where it doesn't make sense:

{   
    // lessc prod
    prod: {
        globals: [
            "custom/less/variables.less",
            "custom/less/mixins.less",
            "bootstrap/less/mixins.less"
        ],
        less: [
            "bootstrap/less/reset.less",
            "bootstrap/less/scaffolding.less",
            "bootstrap/less/grid.less",
            "bootstrap/less/layouts.less",
            "bootstrap/less/type.less",
            "bootstrap/less/other-components.less"
        ],
        minify: false,
        css: {
            "assets/css/project.css"
        }
    }

    // lessc dev
    dev: {
        globals: [
            "custom/less/variables.less",
            "custom/less/mixins.less",
            "bootstrap/less/mixins.less"
        ],
        less: [
            "bootstrap/less/reset.less",
            "bootstrap/less/scaffolding.less",
            "bootstrap/less/grid.less",
            "bootstrap/less/layouts.less",
            "bootstrap/less/type.less",
            "bootstrap/less/other-components.less"
            "bootstrap/less/docs.less"
        ],
        minify: false,
        css: {
            "assets/css/project.css"
        }
    }

    // lessc components
    components: {
        globals: [
            "custom/less/variables.less",
            "custom/less/mixins.less",
            "bootstrap/less/mixins.less"
        ],
        minify: false,
        files: {
          "assets/css/alerts.css": "assets/less/alerts.less", // right compiles to left
          "assets/css/buttons.css": "assets/less/buttons.less",
          "assets/css/button-groups.css": "assets/less/button-groups.less",
          "assets/css/carousel.css": "assets/less/carousel.less",
          "assets/css/dropdowns.css": "assets/less/dropdowns.less",
          "assets/css/modals.css": "assets/less/modals.less"
        }
    }
}

the first two objects, prod and dev, are just two examples of grabbing a library of less files and compiling to one css file, along with the option to minify or not. In both examples a path for less is defined, and a path for css is defined, since we do not need to compile more than one css file.

the last object, components, shows each less file compiling to a separate css file.

One more thought is that the "globals" concept adds a lot of value but it does not necessarily need to be included in this. If just the compiling options (using json) are implemented I'd be that much happier :)

[matthew-dean]

Damn, I totally missed that you gave great comments on this. Probably because I was taking care of a new human at the time. ;-)

This thread could continue on #1134, but one thing that doesn't make sense is the inclusion of files. That seems utterly unnecessary. The parser will find those based on their include statements. It doesn't need them to be explicitly declared, and doing so would just add a maintenance headache. Otherwise, some great ideas here.

[jonschlinkert]

lol, thanks and congrats! We have a two-year old. I was just through that myself!

Yeah, I agree with your point about inclusion of files. After playing around with configurations similar to what I suggested for the last few months, I think I would do things differently now, like as I proposed in the issue you linked to.

I think if you compare the .json idea to the native less @options one-to-one, the advantage of @options is that you can accomplish everything you could with json, with all of the advantages, and none of the disadvantages. Namely, the you wouldn't be required to have an external file specifically and only for options, as you would with .jshintrc for instance. I actually like the jshint options concept, but in that scenario the options are actually written in the same language as the tool consuming them. That wouldn't be the case if we used less.json or whatever for options. And I'm one of those folks that likes having an external options file sometimes, because it's easy to share with collaborators and other projects, so with @options there is nothing stopping me from doing that and putting everything in an options.less file. I can't see any advantage of .json over that. Less will always know what to do with @options, regardless of the build tool.

Another cool thing about the @options idea that didn't occur to me until now, it's kind of like having yaml front matter, except much more flexible since 1) it's not yaml, and 2) it doesn't need to be "front matter" lol, it can be anywhere. But the operative point is that would give a similar ability to set and control context as you would with yaml front matter or mustache.

[matthew-dean]

Yes, for all the reasons above, it's a good idea. You've made a strong argument for the LESS/CSS-like syntax for an options block.

Now we just need an implementation / pull request.

[doowb]

@MatthewDL I'll take a shot at working up an implementation for this.

[jonschlinkert]

I think @doowb meant an implementation for #1134. Correct, Brian?

[doowb]

@jonschlinkert yes, I was talking about the @options issue.

[lukeapage]

@kievechua and anyone else - do you think the options should be json or are you happy for them to be less - if you are happy for them to be less, I am thinking we may as well close this.

[Soviut]

I think LESS syntax makes the most sense. We can assume anyone using LESS is familiar with CSS, however we should not assume they would be familiar with a different language and syntax such as JSON.

[jonschlinkert]

I agree, let's close this for now so we can focus on LESS-flavored options. We can reopen if necessary.

[matthew-dean]

+1 to @Soviut's point, but looks like we resolved this anyway.

[matthew-dean]

Based on the further discussion that happened with @options, it looked like JSON may in fact work better to implement first (for build systems). Configuration is easier at the JS / JSON level, and makes sense to include parser directives in JavaScript.

It's possible we could support both, but either way JSON should be one of those options, so we might as well implement first.

[matthew-dean]

Closing, discussion moved to #1893.