sindresorhus/compass-task.md

## compass-task.md

      
    Raw
  

              compass-task.md
            
          
    Compass task options - feedback wanted

Need some feedback on how to handle the Compass options.
The problem is that Compass doesn't expose all it's options through the CLI. CLI parameters aren't even documented. This has been a problem for us in Yeoman, since we need an option only available through their config.rb config file.
The idea is to drop the CLI parameters and dynamically create a temp file that we feed into compass from the options specified in the gruntfile.
Currently compass options looks like this:
project_type = ":stand_alone"
chunky_png_options = {:compression => Zlib::BEST_COMPRESSION}"
Config reference: http://compass-style.org/help/tutorials/configuration-reference/`
I've prepared some options for us:
(This is in addition to be able to specify an external config.rb file of course)
Option 1


Drop CLI parameters
Generate temp config.rb and feed it into compass

We don't normalize anything but let users just use the syntax directly from the Compass docs.
compile: {
  options: {
    'sass_dir': 'sass_dir = "test"'
  }
}
Here we only use the key so the item can be extended and let the value be up to the user, each item is one line in the config.rb. This would also allow stuff like:
add_import_path "/Users/chris/work/shared_sass"

Another benefit of dynamically generating the config.rb is that it works with multiple targets. You could of course specify a separate config.rb file for each target, but I don't really like that, since you then have to manage multiple configfiles (gruntfile, config1.rb, config2.rb) and they the options are no longer extendable.
Option 2

Generate config.rb file as above, but this time try to normalize the values.
compile: {
  options: {
    sassDir: 'test'
  }
}
This would mean a lot of code to convert the object to valid Ruby data types and stuff. Also error prone and magic. And examples in doc could not be used directly. Obvious benefit is that it's more JS like. This would also mean you couldn't stuff like:
add_import_path "/Users/chris/work/shared_sass"

Option 3

Just use CLI options and have a extra item called raw where you can specify some configs that aren't available through the CLI.
compile: {
  options: {
    sassDir: 'test',
    raw: [
      'add_import_path "/Users/chris/work/shared_sass"',
      'http_javascripts_path = "/test"'
    ]
  }
}
Option 4

We could also not camelCase the keys here, but then JSHint would complain, of course we could quote them to fix that again, but yeah.
compile: {
  options: {
    'sass_dir': 'test',
    raw: [
      'add_import_path "/Users/chris/work/shared_sass"',
      'http_javascripts_path = "/test"'
    ]
  }
}
--
Feedback


Which solution do you prefer? Why?


Compass is usually run just using from-to folder options (sass_dir and css_dir), should we keep it as that or should we hack in the grunt file handling (src and dest)? If we do this we'll introduce some magic and inconsistency with the Compass community.