feature request: : Add a flag to turn off DEPRECATION WARNS

[luiscla27]

Since version 4.9 of node-sass the current warning is being shown in a lot of projects. (you may see an open issue asking for a way to silence the warning here)

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

The warning is ok and i would love to fix all my deprecated functions call but i can't, the main reason is that i don't even know which library is the one with the issue... (is not my code) i understand the need to force everyone to update their deprecated stuff, but that's not feasible. I think every developer is responsible for their own application and taking the risk to be outdated is on their own, i accept the responsibility :)

And so... this feature request is to add somewhere somehow a flag that can be turned on/off the DEPRECATION WARNINGS

I've already mistakenly tried to add an environment variable at the node-sass project, but @nschonni told me that the PR should be done here at libsass, however @xzyfer told me that the acceptable solution to silencing deprecation warnings is to fix the deprecated code, even thought that the code belongs to someone else, a library.

• You may se the code to add the flag is already available at PR-2587 from node-sass project, is not much.
• Also the open issue regarding this matter is 2334 (also from node-sass project).

[luiscla27]

I think i have a more standard solution, what do you all think about implementing log levels?? (like log4j, winston, etc).

Please tell me if you agree more on this :) (so i'll modify this FR title)

[xzyfer]

We will not be adding logging levels, nor will we enable silencing deprecation warnings. These warnings are critically important for user code to continue working.

We would however consider solutions that make it easier to find the code using deprecated behaviour.

[luiscla27]

Thank you for answering all my concerns with this @xzyfer... btw, i've found the library with the problem so the fix is in progress for me 👍

And so... i guess everyone else use cases it'll have to wait until the library owners decide to fix their deprecated stuff (...)

Please remember that this warnings are not critically important to continue our work as developers... if they were like that, an error would be thrown instead of a warning.

[mgreter]

An alternative approach could be #2862 ...

[luaVolk]

This is really important. I'm currently getting dozens of the same error.

DEPRECATION WARNING on line 29 of sass/elements/image.sass:
#{} interpolation near operators will be simplified in a future version of Sass.
To preserve the current behavior, use quotes:

  unquote("image_size_#{$size}")

with something like this

+_(image_size_#{$size})

I'm not even sure what operator it's referring to, but I would much rather change to the "simplified version" when it comes than write that awful looking alternative.

These warnings are critically important for user code to continue working.

Yes I agree @xzyfer , but I already have read these warnings and I want to put them to the side for the time being and focus on other things, but i cant because these warnings fill up the entire terminal

[xzyfer]

There is no intention to support this at this time. Deprecation warning are critically important to us evolving the language. Muting deprecation warning is just deferring pain for when the breaking change is introduced which our issue tracker will enjoy flooded. To remove the warning downgrade to a version of Libsass that predates the introduction of the warning.

[luaVolk]

Warnings are only useful the first time you read them. If someone turns them off is because they already read them and are tired of them and therefore are aware of them, showing it again will not make zero difference, and in the future they will know why it broke.
Not letting people surpress these warnings isnt helping anybody, its just annoying.

[luaVolk]

Also the warning is about how it will become more simplified and the solution it gives to make it much more overcomplicated.
You can see why someone wouldnt want to follow that suggestion, specially when i use it all over my project

[luiscla27]

@xzyfer you have a good point on this!! i agree with you :)

Muting deprecation warning is just deferring pain for when the breaking change is introduced which our issue tracker will enjoy flooded

However i think we can still find a solution!! for most developers complaining about this. The main reason is this part (as @luaVolk said):

I'm currently getting dozens of the same error.

What do you think of reducing all those warnings to just one?? at my case when i opened this feature request i was receiving about 100k+ warnings. I think you can remove all of the "detailed warnings" and just print:

Your libsass implementation is deprecated and will be illegal in Sass 4.0, for more details try '--libsass-verbose'.

And maybe add:

The following errors were found:
> 12 errors found: #{} interpolation near operators will be simplified in a future version of Sass
> 4 errors found: Passing a string to call() is deprecated and will be illegal
in Sass 4.0. Use call(get-function("variable-exists")) instead.

Or something like that... i hope you get the idea, what do you think @xzyfer?

[luiscla27]

I guess my last comment is worth to be a managed as a different feature request (?)

[rationalthinker1]

Do I need 500+ warnings everytime I do a build?

[robertvanhoesel]

(...) critically important to us evolving the language. (...) To remove the warning downgrade to a version of Libsass that predates the introduction of the warning.

I guess suggesting users to pin older versions does not really help adoption and thus evolving the language either.

[thasmo]

Due to this I can't read the build log, which messes up DX and productivity quite a lot.

These warnings are critically important for user code to continue working. We would however consider solutions that make it easier to find the code using deprecated behaviour.

That doesn't help to much when using third-party code/libs.

At the moment this is unusable and I have to pin an old version, for now.

[jakajancar]

The key problem here I think is that no overlap was given: no version exists to pin that both doesn't warn (so you don't get spammed) and supports math.div (so that you can migrate your own code). quiteDeps does not work in all scenarios.

[luiscla27]

@xzyfer are you willing to accept a contribution from the community to make this a reality?? I might be willing to dedicate some of my spare time to it :)

What do you think of reducing all those warnings to just one?? at my case when i opened this feature request i was receiving about 100k+ warnings. I think you can remove all of the "detailed warnings" and just print...

[Rush]

There is no intention to support this at this time. Deprecation warning are critically important to us evolving the language. Muting deprecation warning is just deferring pain for when the breaking change is introduced which our issue tracker will enjoy flooded. To remove the warning downgrade to a version of Libsass that predates the introduction of the warning.

Yes sure - but I can't drop everything I'm doing to upgrade old bootstrap which literally brings no business value at this time. I've been warned, I get it. I don't need the warning 500 times. If anything, one time is enough. :)

[CHEWX]

This is painful. 1 warning is sufficient.

[noahtallen]

@xzyfer I've been finding that the deprecation warnings fill up the entire build log, and often makes it impossible to see any other build errors. I've even gotten a few unexpected out of memory errors. I think it would be beneficial to at least try to minimize the number of warnings shown to avoid build performance issues.

To be fair, the segfault is forcing me to fix the warning everywhere before merging anything which updates sass. Maybe that's a good thing overall! Though, I think folks are frustrated because the effective behavior of the "warning" is obviously now a breaking update and/or a build error. If the goal is to give folks time to update, it shouldn't have the behavior of an error. If the goal is to get everyone to fix the syntax before updating to newer versions, it should be a major version update or at least an actual build error.

[davidli3100]

Another unexpected issue: using external libraries that are locked to a certain version due to licensing changes. There's absolutely nothing that can be done about deprecation warnings in that case unless we wanted to start maintaining a fork of that library.

[LuukvE]

Time to switch back to node-sass.

[TheNaderio]

I cannot go back to node-sass because I'm using a MacBook with M1 chip. node-sass will not support the new chips (if i've read correctly).
So I switched to libsass and got instantly a few deprecation warnings. (few doesn't means the amount, but the (kilo)meters in the log...).

Now I read this issue and it seems that I cannot disable this warnings? <--- 😯😱

I'm switching back to version "sass": "~1.32" (installs 1.32.13) which seems the last version that doesn't spam you all the day. Mostly I like to use the latest versions of a software, but in this case I have to do an exception because of a (in my opinion) bad decision that I can partially understand.
Maybe I'm wrong and there is a way to silence this warnings - then please share it here 🙏🏻

[Morgul]

I think the problem that a lot of people are facing (myself included) is that these warnings are from libraries that we either can't (or won't) upgrade. I think it's perfectly reasonable for that to lock us in to a specific version. And, it's really important for us to know that we're going to be in that boat, so I get the desire not to hide this information from the user.

The problem comes in that with the verbosity of the warnings, even a half dozen makes it really hard to read through debugging logs with these mixed in there as well. For example, my situation is I use bootstrap v4. It doesn't seem like the bootstrap project will ever upgrade v4 to fix these deprications. I can't upgrade to v5 until the library I'm using to integrate with my UI framework of choice upgrades, and I've got several projects already in production that won't be able to be updated to a new version like that for 18 to 24 months, but still need to be maintained. So, realistically, I'm going to be dealing with these warnings I can do nothing about for years. That's frustrating.

What about a way to silence the details of the errors, and instead simply print out "DEPRECATION WARNING: This project uses deprecated syntax that will be removed in Dart Sass 2.0.0. (details silenced.)". I'm fine with a few lines, that print once. But scrolling my debug logging, with other things in between is just very frustrating.

[alkah3st]

It's really incredible that you guys won't deign to create a simple flag for this. There are so many legitimate reasons why one might want to turn off deprecation warnings.

[Rush]

Imagine booting your old Amiga and instead of going into Workbench in its usual 30 seconds, you would see a 1000 deprecation warnings because of the system being deprecated for over three decades now. Do you need a reminder that it's deprecated every time you boot it? Let alone one thousand times each time you boot.

[matthewerwin]

Seems this is even less useful to litter the console during a build because if you're using libraries such as Material or Bootstrap you get warnings caused by downstream libraries.

At this level of warning output and zero filtering you basically obscure real problems b/c it's conditioning developers to ignore warnings entirely.

Furthermore, advance deprecation warnings aren't even actually relevant to the existing behavior of the compiler. Why not simply warn in the version that would actually break that behavior? People can't control the 3rd party libraries...so they're left to counter-productively ignore & so the warnings hold zero weight to anyone.

[TheBrenny]

I'm tracking that this isn't a #roast thread, but isn't the whole point of SemVer so that you can bump the major to 4, effectively removing the guarantee of backwards compatibility? Then you can finally push people to evolve. 🤷‍♂️

[adamkdean]

The only roasting that is happening here is the roasting of DX by 1000s of warnings that I saw the first 400 times they were printed

[Ivan-SB]

It's pretty normal to have log levels and directives to suppress warnings by type/class.
That's because there are MANY circumstances where that makes sense.
These kind of features can get pretty sophisticated and for a reason.

I'd find a "There is no intention to support this at this time because we don't have time and we have different priorities" way more understandable and reassuring for the quality of the project than the one given.