Added an environment variable to suppress DEPRECATION WARNS - Issue #2334

[luiscla27]

Added env variable called NODE_SASS_NO_DEPRECATION, so everyone can be able to disable deprecation warnings.

Warnings will stop being shown by setting the variable NODE_SASS_NO_DEPRECATION to 0

This is related to issue #2334, you may modify variable name and configuration value as you wish, the idea of this PR is just to give everyone some hope of a possible solution.

[luiscla27]

I guess checks fail because the NEW variable needs to be added to the test environment.

[nschonni]

Sorry, we can't make changes to the files in the libsass folder as that is just pulled in from upstream

[luiscla27]

So there's a way to achieve the same results by modifying something somewhere else?? this PR was intended to be a suggestion, do you know where is the upstream folder @nschonni ?

[nschonni]

The upstream project is https://github.com/sass/libsass
I'm not 💯 but I think the next pull of libsass will have removed the things that the deprecation warnings were talking about

[luiscla27]

Thank you @nschonni! the deprecation warnings are being shown on sass implementations (not sass itself), i'll try to make this PR there :)

[xzyfer]

This is not a feature that will be accepted upstream. The acceptable solution to silencing deprecation warnings to fix the deprecated code. In this rare case we're rolling back the deprecation warning because there isn't yet a reasonable way to resolve the warning.

…

On Fri., 1 Feb. 2019, 1:43 am Luis Carlos Limas ***@***.*** wrote: Thank you @nschonni <https://github.com/nschonni>! the deprecation warnings are being shown on sass implementations (not sass itself), i'll try to make this PR there :) — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#2587 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAjZWFrD39JQgXJy00SO3Witc5Moa4grks5vIwEHgaJpZM4aaiBW> .

[luiscla27]

But @xzyfer ... as stated at issue #2334, how do i modify code that doesn't belong to me??

I don't even know which library is the one with the issue... 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'll not make de PR, instead i'll just add a feature request to solve this.

[xzyfer]

You modify the code by opening a PR. Leaving the code unfixed is a time bomb. The code will stop working in a future releases. The deprecation warnings a signals l to the community at large. If you cannot find the code causing the deprecation warning that's a different issue. We should make that easier. That's is a feature we would consider. However controlling the output of deprecation warnings is not something that will change.

…

On Fri., 1 Feb. 2019, 3:11 am Luis Carlos Limas ***@***.*** wrote: But @xzyfer <https://github.com/xzyfer> ... as stated at issue #2334 <#2334>, how do i modify code that doesn't belong to me?? I don't even know which library is the one with the issue... 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'll not make de PR, instead i'll just add a feature request to solve this. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2587 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAjZWKUcAEOeiePa-Z2SHZkENVNinEPcks5vIxW_gaJpZM4aaiBW> .

[luiscla27]

Most fwk's/libraries already expose warnings this same way, i understand the need to force everyone to update their deprecated stuff, as you said... the code will stop working on future releases. Thats same reason that every other lib "warns" developers of the risk.

@xzyfer, the library/fwk responsibility is to provide a solution by upgrading the code... taking the risk of "don't upgrade" is a time bomb, but is a time bomb that usually the developer explicitly silenced,

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.

[Tofandel]

But they're warning, so we get them once and then we know we'll need to update the codebase or a dependency when we want to update to the next major release, but in the minor releases there is so much things being deprecated that those warnings from other libs are just polluting the build process if we update minor, so yes a way to disable them would be welcome

Sure it will break in the next major and we won't have warnings to tell us about it, but we'll be expecting that, that's what a major is for. I think builds should by default be without those warnings and that they should only show with a verbose build with a flag