Disable "DEPRECATION WARNING"s

[janrembold]

We're using gulp-sass package that is only a wrapper for node-sass.

We encounter lots of deprecation warnings like:

DEPRECATION WARNING: Passing a string to call() is deprecated and will be illegal
in Sass 4.0. Use call(get-function("variable-exists")) instead.

This is a valid warning and is related to an old version of Susy Grid. But it is extremely annoying during our development process because it produces hundreds of warnings on each execution of the Sass task.

It would be really great to be able to disable these warnings somehow. Or at least show them only once and not on each execution.

Is there a chance to do that or do you already plan to update this behavior?
Thanks in advance!

[fgarcia]

After upgrading to 4.9 I am getting lots of these warnings from my dependencies.

I want these warnings if it is in my own code, but I would like to disable them if it is in code I do not control

[xzyfer]

There's no way for the compiler to differentiate between code you own and code you don't.

These deprecation warnings are important. They're telling you that your code will cease to work very soon, and you should take steps to resolve the warnings asap.

If it's code you don't control then we recommend opening issues on the code's repo, or submitting a PR to resolve the warnings.

There is simply no way to disable these warning. If you don't want to see them I suggest downgrading to an older version of Sass and never updating again.

[xzyfer]

We'll look at what's involved in deduping the deprecation warnings but we can't make any promises at this time.

[igorlakic]

I get the same warning when using gulp-sass with SingularityGS... I saw a fix for the same problem in another project - can something like this be a good solution here too?

[xzyfer]

Yes, this is exactly what needs to be done for the libraries causing these deprecation warnings. It should be easy enough to do for anyone with the time.

[esteinborn]

@xzyfer I'm wondering if there is a way to print the file that those deprecation warnings are generated from during compilation? I have a large project with many references to functions this way, but only generating a few of the deprecation messages.

[xzyfer]

So I don't believe we can know the file, and/or location of the offending import for various reasons. However I believe we can at least provide the path and name of the file being imported that is triggering the deprecation warning.

[sebszocinski]

Any updates on this?

[jwahler]

@sebszocinski We worked around this issue by updating our susy grid to 2.2.14. All our warnings were produced by susy. Give it a try. good luck.

[sebszocinski]

Thanks mate

[ChiriVulpes]

Another reason to support disabling these is the #RRGGBBAA string -> color change, as just using them in normal CSS declarations works either way, so I'm being warned pointlessly for every use every time it compiles

[lvl99]

We've had an issue with create-react-app and CI (help for google searches: continuous integration) whereby create-react-app build script would abort on any warnings outputted if CI=true. Since these deprecation notices are warnings, it was halting our CI 🤷‍♂️

[luiscla27]

Some upvotes may help to this humble PR to be considered (#2587) 👍

[luiscla27]

@xzyfer any update about this issue?

[saper]

Closing per sass/libsass#2822 (comment)

[WvanDam]

There's no way for the compiler to differentiate between code you own and code you don't.

These deprecation warnings are important. They're telling you that your code will cease to work very soon, and you should take steps to resolve the warnings asap.

If it's code you don't control then we recommend opening issues on the code's repo, or submitting a PR to resolve the warnings.

There is simply no way to disable these warning. If you don't want to see them I suggest downgrading to an older version of Sass and never updating again.

We have just adopted a repository generating these depreciation warnings. We've seen the depreciation warnings. We have noted them down. We have made a plan to upgrade the dependency causing them. That however requires a full version upgrade that introduces a slew of breaking changes. It represents a significant amount of work that adds no other business value, so it's not something we can justify doing before we do anything else.

So in the meanwhile we repeatedly get 60+ warnings that now add no value, hamper our productivity and actually pose a security risk. Due to the sheer volume overloading the console we run the risk of missing important security messages. So yeah, we downgraded.

I appreciate the intention, but you're effectively deciding for us that non critical upgrades to your library are more important than all sorts of other considerations that we have to deal with. Hard pass.

[luiscla27]

Due` to the sheer volume overloading the console we run the risk of missing important security messages.

Today this issue happened to me, you've finally done it, @xzyfer I got so used to see this warnings all the time that I've learned to just ignore them, it happened the same with all my coworkers (because there's nothing we can do to solve them -they're from libraries-).

So, a bunch of real warnings were printed in our logs and nobody saw them. Thank you so much :)

[xeno]

If you can live with an older version, v1.32.13 was the last version without this deprecation warning.