Node-sass: Disable "DEPRECATION WARNING"s

Created on 16 Apr 2018  ·  15Comments  ·  Source: sass/node-sass

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!

External - LibSass Invalid - Wont Fix

Most helpful comment

@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.

All 15 comments

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

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'll look at what's involved in deduping the deprecation warnings but we can't make any promises at this time.

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?

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.

@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.

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.

Any updates on this?

@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.

Thanks mate

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

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 🤷‍♂️

Some upvotes may help to this humble PR to be considered (#2587) :+1:

@xzyfer any update about this issue?

Was this page helpful?
0 / 5 - 0 ratings

Related issues

paulcpederson picture paulcpederson  ·  3Comments

nagyfej picture nagyfej  ·  3Comments

samayo picture samayo  ·  3Comments

Pixelatex picture Pixelatex  ·  3Comments

cjo2118 picture cjo2118  ·  3Comments