functions option support

[sanniassin]

Since version 3.0.0 node-sass supports custom functions, so it's gonna be great to use it with sass-loader

[sanniassin]

Makes sense, but not sure about conflicts if same option present both in query and sassLoader.

[jorrit]

I'd say that sassLoader overwrites opts. The object-assign module could be used for this.

[sanniassin]

I mean, that two points for setting same options could lead to undesirable behavior with hard to find overrides if you load options for sassLoader from external module or just forgot, that option already set in sassLoader. Anyway it's better to make another PR for this.

[dtothefp]

This may be a moot point because from what I can tell the loader-utils module won't even allow the user to pass an object and have it parsed. I've tried many different methods with no luck webpack/loader-utils#15.

eslint-loader uses the object-assign pattern where the options passed from wepback config task presedence, i.e. matching keys passed from the query string are overwritten by those present in this.options. https://github.com/MoOx/eslint-loader/blob/master/index.js#L98 Although eslint-loader shows in the readme a way to pass rules as object loader: "eslint-loader?{rules:[{semi:0}]}" in the query string, I tried it out in sass-loader and didn't get it to work so not sure that the loader-utils API even supports this?

Update: got passing object as query param to work...duh

I do agree with @jorrit that all keys should be merged, but I would say that those in this.options take precedence over those from parsing the query string as they are less prone to errors. It would also be great to have this behavior because it is currently a pain to iterate over all includePaths and create a query param for each.

Anyhow, it would be great to have this functionality. Not sure if @jhnns would be open to having a dependency on object-assign added? Ultimately, I think there is a problem with @sokra loader-utils API if for somethings such as Objects a different API for passing options i.e. this.options vs parsing this.query to loaders must be used.

[jhnns]

I had this issue several times (webpack-contrib/less-loader#40 peerigon/markdown-loader#8). While passing the options via query parameters is cumbersome, I don't think that it would be a good idea to pass-in all options via the webpack config. It seems straight-forward, but the full module path + query string is used as cache id afaik. Hence, two require calls with different loader configs are recognized to be different.

What do you think about it @sokra?

[jhnns]

@sanniassin anyway, thx for your PR. I'm willing to merge this, but could you also add tests please?

[jhnns]

Nevermind... I'll do it, because we need a better setup for these kind of tests.

[sanniassin]

Thanks, as i've never used mocha before :)

[dtothefp]

@jhnns thanks for the help on this. I know it sucks for caching but seems like for complex config this is necessary in webpack

[jhnns]

@dtothefp It is necessary for options that can not be stringified using JSON.stringify

[jhnns]

Shipped with 3.1.0. New preferred way for passing options is now via a property on your webpack config. See https://github.com/jtangelder/sass-loader#sass-options