DeprecationWarning: context.fix is being deprecated with stylelint 16.8.2

[sebbayer]

With the latest stylelint version 16.8.2 I get lots of deprecation warnings because context.fix is being deprecated:

(node:4037) [stylelint:005] DeprecationWarning: context.fix is being deprecated.
Please pass a fix callback to the report utility of "scale-unlimited/declaration-strict-value" instead.

See 16.8.2 changelog: https://stylelint.io/changelog/
And the PR: stylelint/stylelint#7895

[AndyOGo]

Thx a lot.
https://stylelint.io/developer-guide/rules/#add-autofix

[silverwind]

FYI, with Stylelint v16.9.0, a workaround is available via NODE_OPTIONS=--no-deprecation to suppress the warnings.

[kliehm]

Yeah, so it's deprecated. As an end user, I call it with the CLI and the --fix suffix. Is there anything else I can do to make this annoying message go away? Should I edit my .stylelintrc.cjs file? I don't use context.fix anywhere, I'm not a Stylelint contributor.

[silverwind]

Is there anything else I can do to make this annoying message go away

You could downgrade stylint to 16.8.1, before the deprecation was introduced.

[kliehm]

@silverwind @AndyOGo I don't understand, aren't you going to fix this? Or did you already fix it? If so, in which release?

[AndyOGo]

@kliehm
You find the answer to your question in the release notes of stylelint.

Fixed: honour Node.js --no-deprecation flag for rule deprecation warnings (stylelint/stylelint#7943) (@Mouvedia).
https://github.com/stylelint/stylelint/releases/tag/16.9.0

Thank you.

[bencebkiss]

@kliehm You find the answer to your question in the release notes of stylelint.

Fixed: honour Node.js --no-deprecation flag for rule deprecation warnings (stylelint/stylelint#7943) (@Mouvedia).
https://github.com/stylelint/stylelint/releases/tag/16.9.0

Thank you.

With all due respect, it's just a workaround, not an actual fix.

I think it's better to fix the root cause instead of just ignoring the deprecation warnings. That's what most of us need in order to use this package properly.

[AndyOGo]

Thank you for sharing your idea.

Please understand that this is a deprecation, it's not a bug or something broken.
You get a warning and styelint provides a way to hide those - the new API will be enforced in the next major version and then this plugin will update.

(computing) the fact of a software feature becoming outdated and best avoided because it has been replaced with something newer
https://www.oxfordlearnersdictionaries.com/definition/english/deprecation

[ScorpAL]

OMG... Stop arguing please.

...
"stylelint": "^16.10.0",
"stylelint-config-clean-order": "^6.1.0",
"stylelint-config-standard-scss": "^13.1.0",
"stylelint-declaration-strict-value": "^1.10.6",
"stylelint-use-logical-spec": "^5.0.1",
...

I still see

...
(node:16392) [stylelint:005] DeprecationWarning: `context.fix` is being deprecated.
Please pass a `fix` callback to the `report` utility of "scale-unlimited/declaration-strict-value" instead.
(node:16392) [stylelint:005] DeprecationWarning: `context.fix` is being deprecated.
Please pass a `fix` callback to the `report` utility of "scale-unlimited/declaration-strict-value" instead.
(node:16392) [stylelint:005] DeprecationWarning: `context.fix` is being deprecated.
Please pass a `fix` callback to the `report` utility of "scale-unlimited/declaration-strict-value" instead.
...

just when scale-unlimited/declaration-strict-value config added.
Like:

'scale-unlimited/declaration-strict-value': [
    ['/color$/', 'fill'],
    {
        expandShorthand: true,
        ignoreValues: ['transparent', 'currentcolor', 'inherit'],
        autoFixFunc: autoFixFunc,
        disableFix: true
    }
]

not matter with or without autoFixFunc or disableFix: true

Firstly I thinking that disableFix: true should help me,

While you continue fighting, for me better to comment this config (or disable 'scale-unlimited/declaration-strict-value') rather then downgrading for styleint.

[AndyOGo]

@ScorpAL

Stylelint offers a workaround to suppress those deprecation warnings.
This has been pointed out first by @silverwind

FYI, with Stylelint v16.9.0, a workaround is available via NODE_OPTIONS=--no-deprecation to suppress the warnings.
#379 (comment)

Then a second time by myself.

@kliehm You find the answer to your question in the release notes of stylelint.

Fixed: honour Node.js --no-deprecation flag for rule deprecation warnings (stylelint/stylelint#7943) (@Mouvedia).
https://github.com/stylelint/stylelint/releases/tag/16.9.0

Thank you.
#379 (comment)

---

The migration will happen with the next major version of stylelint.

[ScorpAL]

@AndyOGo thanks.

I have used --quiet-deprecation-warnings temporarily in my package.json scripts

"scripts": {
    ...
    "lint:css": "stylelint src/**/*.{css,scss} --quiet-deprecation-warnings",
    ...
},

https://stylelint.io/user-guide/options#quietdeprecationwarnings

[myovchev]

I was forced to completely disable the rule in our stylelint config package because:

• I don't want to add flags to dozens of packages + customers using it.
• I don't want to do the same once the problem is resolved
• I don't want to silence deprecation warnings on everything (if using NODE_OPTIONS).

Why was important to get rid of the warnings:

• It nearly breaks CI (large codebases).
• It's extremely slow and annoying when it runs in local development.

I'm not aware of the context so I can't participate in the discussion. My desire is to use a package and get a clear but useful solution - a simple configuration, that solves a problem in hand. The simple principle that I'm following is: the fellow dev didn't do anything wrong (no misconfiguration or stupid code), so everything that comes as a problem after that and is a pain. is something that has to be resolved in a satisfactory for everyone way.

[AndyOGo]

Stylelint offers multiple ways to disable their deprecation warnings.

You find that information in different parts of their documentation (I kindly advise to read the full documentation so that you get the full concept of it).

1. via quietDeprecationWarnings Option
   Attention: please note that at the very top it is defined how those options may be used

   Options shared by the:

   • CLI
   • Node.js API
   • PostCSS plugin
     You can use some of these options in the configuration object.
     https://stylelint.io/user-guide/options

   1. via their CLI's stylelint --quiet-deprecation-warnings arg
   2. via their Node.js API Options
   3. via their PostCSS plugin Options
2. via NODE_OPTIONS=--no-deprecation environment variable
   • this is based upon the official Node NODE_OPTIONS=options... list of command-line options feature

Note: stylelint configurations are shareable by default (so no need to repeat a config that you want to re-use).
https://stylelint.io/user-guide/configure#extends

---

@myovchev

• I don't want to add flags to dozens of packages + customers using it.

You can always share styleint configurations - no need to manually update dozens of stylelint configurations manually (npm update is sufficient)
https://stylelint.io/user-guide/configure#extends

• I don't want to do the same once the problem is resolved

When the deprecation is migrated you only need to update. (quietDeprecationWarnings is a core stylelint feature and is in no way related to this plugin)

• It nearly breaks CI (large codebases).

Okay.
This concerns me a lot, are you sure that your CI can be nearly broken by verbose logging?
If that is the case, please report it to your CI provider.

[AndyOGo]

Update

I just released an unsafe monkey patch of node's process.emitWarning API as v1.10.7 to suppress any stylelint related deprecation warnings in relation to this plugin.

For further information why this approach was choosen, please see the ticket at stylint:
stylelint/stylelint#8249

Further more node recently added --disable-warning command-line option to give users more fine-grained control of which warnings to disable.

I will leave this ticket open until the next major version of stylelint is released and the context.fix API is completely removed (including this monkey patch).

[ahenriksen-inferno]

Update

I just released an unsafe monkey patch of node's process.emitWarning API as v1.10.7 to suppress any stylelint related deprecation warnings in relation to this plugin.

For further information why this approach was choosen, please see the ticket at stylint: stylelint/stylelint#8249

Further more node recently added --disable-warning command-line option to give users more fine-grained control of which warnings to disable.

I will leave this ticket open until the next major version of stylelint is released and the context.fix API is completely removed (including this monkey patch).

@AndyOGo - Thank you very much for the monkey patch release! 🐵 For my needs, this approach works much better, and I appreciate you taking the time to implement it.

[myovchev]

@AndyOGo Thanks for the effort. I completely understand and share the hesitance to introduce anti-patterns in your code. I did follow the discussion you linked here and I do like the argumentation in this comment. I could write a whole article on "Why deprecation warnings that can't be muted are evil". And when I say "can't be muted" I include those that can be muted on a process level. Why? Because in some cases we don't have control over the process. Think of shared configs between hundreds of projects (or even bigger number when it's a popular public config). We need a configuration control over the warnings. It's even worst when the end user doesn't understand (and don't need to understand) why this warning is there in a first place (internals should be kept internal).

With that said, without knowing any internal logic, I'd say this is a problem of how stylelint introduces warnings, the plugin authors and end users are bearing the consequences. Also it looks like the stylelint community wants and will find a solution in the near future (deducing from what I'm reading in referenced discussions). These are all good things.

This is not a unique for stylelint community problem. Not so long ago there was a similar problem with a Sass release that did put the world on fire. The initial response of the developers was "this is the right thing to do, it should be in your face". This changed shortly after and now I'm able to mute warnings per ID (unique name) directly in my Vite config.

Why this all matters? Muting a warning is a part of a the contract between a vendor (a package) and user (a developer). There are clear responsibilities and a safety protocol. Explicit opt-out of a specific deprecation warning means "I understand the implications". Semver helps me handle it properly. I'm aware that I'm stuck with a major version. I can also plan what is the right time to fix my code based on the expected effort.

I understand the position of a plugin author is unique, because all kind of public API, BC, FC constraints. I'm grateful that you took an extra mile in an attempt to fix this mess. Cheers!