Default options via js file

[chriseppstein]

This came up from an eyeglass issue: https://github.com/sass-eyeglass/eyeglass/issues/44#issuecomment-140175505

I'd like to be able to do node-sass --defaults my-node-sass-defaults.js

where my-node-sass-defaults.js can be either a javascript or json file that would be required and whatever is exported will be assumed to be a js object that is the defaults for compiling.

This would allow for trivial eyeglass integration or to pass other options that cannot be represented as CLI args (E.g. importers/functions)

[xzyfer]

We've previously discussed configuration at length. Our primary concern was how to prevent custom importers and custom functions negatively affecting code portability like we see in the PostCSS ecosystem.

We agree that being able to autoload a set of custom importers and functions would ease the cognitive burden of using the CLI. We however see this a subset of a larger configuration problem.

What happens if you depend on a 3rd party module that expect a custom function to have been loaded? It's either on your, or the 3rd party module's author to explicitly load the dependency. We think the responsibility lies with the 3rd party module's author.

Internally we load certain configuration from the nodeSassConfig object in our package.json. Our plan was to either extend this to support an importers and functions array, or move to an rc file format like .eslintrc. This would allow module to declare the importers and/or functions they expect (which also need to be an npm dependencies of that module) and we'll autoload them.

[chriseppstein]

FWIW, ruby sass has this same philosophy as node-sass and ruby-sass has the -r option (and the --compass option) that effectively supports this.

What happens if you depend on a 3rd party module that expect a custom function to have been loaded?

The important thing from an ecosystem perspective is to allow modules and their dependencies to be stated explicitly. npm gives most of that for free but it has to get loaded into node-sass.

This is basically the problem that eyeglass solves, but until the community settles on a "winner" in the sass modules for node-sass space, it makes sense to support them all via some generic interface like the one I requested here.

negatively affecting code portability like we see in the PostCSS ecosystem

The postcss issue arises because of the extreme nature of this problem. Loading functions and importers into options passed to node-sass is not going to kill an ecosystem -- it might just make it bumpy to get started.

PostCSS actually has a good solution to this problem now. The @use directive loads a post-css plugin for just the current file. If the plugin is not found, the user gets an error.

[kristerkari]

I would like to bring back the discussion of a config file for node-sass.

Ideally there would be a plugin, like this one for postcss, that allows loading config from multiple supported formats: https://github.com/michael-ciniawsky/postcss-load-config

I think that it's a great thing that PostCSS supports that, and it would be good to have in node-sass too.

I used that postcss config loader for my React Native postcss transformer, but for the Sass version I have no simple way for the user to define custom node-sass options.

Adding support for an rc file would be already good enough, and supporting options from package.json would be even better. I would be interested to helping out if there some decision about which format(s) to support.

What do you think @chriseppstein @xzyfer?

[kristerkari]

Bump, I would really like to get some discussion or opinions about node-sass supporting a config file.

[xzyfer]

My current thinking is that we'll supper sass.rc file.

On 10 Mar. 2018 10:01 pm, "Krister Kari" notifications@github.com wrote:

Bump, I would really like to get some discussion or opinions about node-sass supporting a config file.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/sass/node-sass/issues/1144#issuecomment-372021425, or mute the thread https://github.com/notifications/unsubscribe-auth/AAjZWPvla43hoQU6em2prhPiceWHaeJoks5tc7J1gaJpZM4F9E6B .

[kristerkari]

Great, let me know if there is anything that I can help with to get that forward 👍

[xzyfer]

I'm curious to know what kind of config people would like to set. Include paths are the obvious one.

On 10 Mar. 2018 11:37 pm, "Krister Kari" notifications@github.com wrote:

Great, let me know if there is anything that I can help with to get that forward 👍

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/sass/node-sass/issues/1144#issuecomment-372026677, or mute the thread https://github.com/notifications/unsubscribe-auth/AAjZWC_1Fdgu530RDWxb5RY4UzhMHYSLks5tc8kWgaJpZM4F9E6B .

[kristerkari]

I have been using functions (https://github.com/sass/node-sass#functions--v300---experimental) in a couple of projects. So it would be nice to define those inside the config.

[xzyfer]

Cool. Functions and importers make sense also

On 10 Mar. 2018 11:50 pm, "Krister Kari" notifications@github.com wrote:

I have been using functions (https://github.com/sass/node- sass#functions--v300---experimental) in a couple of projects. So it would be nice to define those inside the config.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/sass/node-sass/issues/1144#issuecomment-372027459, or mute the thread https://github.com/notifications/unsubscribe-auth/AAjZWDitmfPuEorxKt1iiDq6xGfYd9xzks5tc8wvgaJpZM4F9E6B .

[brianfryer]

@xzyfer Here's an config that I'm currently using:

import chromatic from 'chromatic-sass';

const options = {
    functions: chromatic,
    outputStyle: 'expanded',
    sourceComments: false,
    includePaths: [
        './src/',
        './node_modules/'
    ],
    data: '@import "styles/app";'
}

functions, outputStyle, includePaths, and data being the most important for my builds.

I'd love to see a feature like this get implemented!

[rafaelcichocki]

I would like to set "nodeSassConfig": { "binarySite": "http://my-local-node-sass-location" } as described in this issue: https://github.com/sass/node-sass/issues/1419

It's used in https://github.com/sass/node-sass/blob/3ab7a16af9dca7350ddec6fa7046d7def9057230/lib/extensions.js in getBinaryUrl

[xzyfer]

You can set that as an environment variable. Check the documentation for more info. This issue is about a different kind of configuration.

On Tue., 19 Jun. 2018, 10:03 pm rafaelcichocki, notifications@github.com wrote:

I would like to set "nodeSassConfig": { "binarySite": " http://my-local-node-sass-location" } as described in this issue: #1419 https://github.com/sass/node-sass/issues/1419

It's used in https://github.com/sass/node-sass/blob/3ab7a16af9dca7350ddec6fa7046d7def9057230/lib/extensions.js in getBinaryUrl

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/sass/node-sass/issues/1144#issuecomment-398374724, or mute the thread https://github.com/notifications/unsubscribe-auth/AAjZWJADN9o5W8K7aG3EZ4gaC1cD-Z4vks5t-OiFgaJpZM4F9E6B .