Gulp-sass: Data option

[Bitaru]

Hi guys, it seems like a bug - https://github.com/dlmanning/gulp-sass/blob/master/index.js#L36
We may have chance to add extra data to libsass, e.q:

.pipe($.sass({
      sourceComments: !BUILD,
      indentedSyntax: true,
      data: "$ENV: \"" + (BUILD ? "PROD" : "DEV") + "\";",
      outputStyle: BUILD ? 'nested' : 'nested',

What do you think?

[Snugug]

This is not a bug in Gulp Sass. Node Sass's data option is a string to get compiled in to Sass. As we are working within the Gulp ecosystem, we shouldn't be passing file paths in to Node Sass, but rather passing the contents of the manipulated file stream, hence why we use Data.

If you'd like to alter the contents of the file being passed to Node Sass, that should be done through a gulp plugin before getting to the Sass plugin

[Bitaru]

@Snugug agree, so there is no way to define global variables without including different configs? Here is node-sass example with data and function options https://github.com/sass/node-sass#example
Sorry for misunderstanding

[Snugug]

Custom functions, an experimental Node Sass feature, would be the way to do it, as that example shows.

On Jun 24, 2015, at 6:47 AM, Bitaru D. [email protected] wrote:

@Snugug agree, so there is no way to define global variables without including different configs? Here is node-sass example with data and function options https://github.com/sass/node-sass#example
Sorry for misunderstanding

—
Reply to this email directly or view it on GitHub.

[somewebmedia]

@Snugug I think this should be re-opened.

There should be a way to pass additional sass data from gulp, like you can do in node-sass.

It should look like this:

gulp.task('sass', function () {
  gulp.src('./sass/**/*.scss')
    .pipe(sass({
      data: '$someVar: 15px;'
    }))
    .pipe(gulp.dest('./css'));
});

[xzyfer]

I agree with @Snugug. This does not follow gulp semantics. I would look at, if possible in your usecase, looking at the approach I've suggested in https://github.com/sass/node-sass/issues/965#issuecomment-103384773

[somewebmedia]

@xzyfer How does it not follow gulp semantics?

Your approach doesn't solve the need of programmatically adding additional sass code to the render, which you CAN do in node-sass (https://github.com/sass/node-sass#data).

So I don't want to change paths to sass files, I want to create sass code inside a gulp task and pass it.

And there is a really small code change that would allow this to work.

[panthershark]

I'd like to propose another look at this ticket. It seems reasonable b/c gulp-sass is a wrapper for node-sass. In rejecting this PR, gulp-sass is removing the ability to use a supported feature of node-sass. Should that be the role of gulp-sass?

I understand the semantic gulp argument, but it seems more pedantic, than semantic since gulp-sass is merely passing the data argument along to node-sass. Is there a specific scenario in mind where this is becomes a problem for gulp-sass?

[xzyfer]

Gulp Sass should only deal with streams. The expectation in the gulp ecosystem is that the resulting stream from the previous pipe (plugin) is passed through to this plugin. Breaking this assumptions is a net negative for us and the gulp ecosystem as a whole, as well as a potential support nightmare.

I understand the semantic gulp argument, but it seems more pedantic

In the case being pedantic is the right thing. We should act in predictable way for gulp users.
If you need specialised behaviour, building a specialised gulp plugin for your app is trivial.

gulp-sass is merely passing the data argument along to node-sass

Yes, node sass allows you pass arbitrary data to render. However the intention was never the use-case described here. We never intended for people to mutate the users' Sass data. It was designed exactly for gulp style case where streams (rather than files) are the main transport mechanism.

Is there a specific scenario in mind where this is becomes a problem for gulp-sass?

IMO not following the aforementioned gulp semantics is more than enough reason to not allow this.
Security is another concern. Allow this could give someone the way to maliciously modify the users Sass before it's compiled.

---

IMHO doing this is bad for the majority of users, and bad for us a maintainers. If you really need to do this, the semantic gulp way would be intercept the stream before it reaches gulp-sass. This has the advantage that your modifications are clear and obvious to users. I suggest looking into gulp-tap.

[panthershark]

Thanks for the explanation. Makes total sense to me.

[somewebmedia]

@xzyfer Now I see the point. Thanks for the detailed explanation.

[xzyfer]

Happy to help :)

[sgarbesi]

Does this work?

[xzyfer]

@sgarbesi please read the entire issue for the information you need.

[cheapsteak]

Please update the documentation to make it clear which options for node-sass you support and which are ignored.

Wasted quite a bit of time trying to debug what I'm doing wrong because I read this:

Pass in options just like you would for node-sass; they will be passed along just as if you were using node-sass.

[cheapsteak]

What is currently an actual _solution_ for this? (i.e. Passing variables from node to node-sass?)
The one linked to in https://github.com/sass/node-sass/issues/965#issuecomment-103384773 doesn't actually solve the issue but rather sidesteps it for a very narrow usecase of environmental variables

I'm working on a project where sometimes both the JS and the stylesheets need to know what certain breakpoints and path-prefixes are and I'd like to keep a single source of truth in a js file that the gulp file reads from.

Less has modifyVars that you pass in in gulp-less via

.pipe(less({
  modifyVars:{
    '@assetPath': '"' + settings.assetPath + '"',
    '@small': settings.breakpoints.small + 'px',
  }
))

Stylus has define

.pipe(stylus({
  define: {
    'assetPath': '"' + settings.assetPath + '"',
    'small': settings.breakpoints.small + 'px',
  }
}))

I've tried using gulp-add to create an in-memory file that contains the variable declarations, but that seems to be ignored by node-sass which complains about not being able to find the file.

Is the solution to actually create a physical file on my disk before running gulp-sass, and delete that file afterwards? That seems much less in line with gulp semantics

[somewebmedia]

@cheapsteak Use gulp-insert

var insert = require('gulp-insert');

stream.pipe(insert.prepend('$assetPath: "' + settings.assetPath + '"'));

[cheapsteak]

Will that not mess with sourcemaps?
Also it seems to prepend to each file, seems rather excessive no?

edit: does work though, thanks!