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: https://github.com/stylelint/stylelint/pull/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 (https://github.com/stylelint/stylelint/pull/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

[kliehm]

Thank you for sharing you 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

I know what deprecation means. It also means that you need to change something so that it's still compatible in the future. You can't just sit it out. 😄

[AndyOGo]

@kliehm next time before you spam an issue thread.

Please make sure to carefully read and understand the official documentation and release notes. Then please make sure that you are able to evaluate the importance of different aspects of software engineering. Last but not least work on your social competence.

Thank you.

[kliehm]

I would suggest the same. I was asking a reasonable question what your intention is to be forward compatible since there these deprecation warnings which will lead to incompatibility. All you suggested was “switch the warnings off”. That's neither helpful, nor respectful, just ignorant. I'm a senior programmer, not an idiot.

[AndyOGo]

@kliehm No, that is incorrect.

Your question has already been answered two ways.

1. I added a maintenance label on Aug 19
2. That comment on Aug 29 referenced the stylelint release notes and the official way to deal with this until the context.fix API is completely removed

Frankly, you have not accomplished a senior level in programming - that becomes obvious by your lack of understanding of these clear and simple information.

[kliehm]

@kliehm No, that is incorrect.

Frankly, you have not accomplished a senior level in programming - that becomes obvious by your lack of understanding of these clear and simple information.

Please refrain from depreciating people whom you don't know, and stick to the topic.

[AndyOGo]

@kliehm Why is your behavior okay? Why is your cynical and derisive comment acceptable?

You can't just sit it out. 😄

To me it's not acceptable and I insist that you

1. make sure to read and understand official documentation to improve your technical competence
2. work on your manners and your social competence and treat social people with respect and dignity

[kliehm]

I don't need your advice on technical competence. That is beyond your knowledge and competence to give such advice. You don't appear to be very social competent yourself. I hope your future employer reads this embarrassing dialogue.

[AndyOGo]

@kliehm Alright, I got that.

What are log levels? What is verbosity? What are syntactical and lexical grammars? What makes a grammar context free? What is and how to read the Backus–Naur form? What is the visitor pattern? Did you study the syntax specifications of CSS, SASS, Less and other CSS-like grammars?

You know the 101 of them by heart?

Well, you called me ignorant? To carefully study, understand and apply the above one has to be quite the opposite of ignorant.

Maybe you don't realize how invalidating that term really is.

1. (often disapproving) not having or showing much knowledge or information about things; not educated
2. not having any knowledge or information about a particular thing https://www.oxfordlearnersdictionaries.com/definition/english/ignorant

Or you just don't know how much work goes into open source software. This is a social project, free of charge.

[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. https://github.com/AndyOGo/stylelint-declaration-strict-value/issues/379#issuecomment-2317074368

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. https://github.com/AndyOGo/stylelint-declaration-strict-value/issues/379#issuecomment-2445259247

---

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: https://github.com/stylelint/stylelint/issues/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!

[Donov4n]

Does the monkey patch still work? In my case (StyleLint 16.14.1), the deprecation warning is displayed because the monkey patch tries to check the presence of the rule name in message when it only appears in options.detail :

---

In my StyleLint 16.14.1, I have the following arguments for emitWarnings:

[
  '`context.fix` is being deprecated.',
  {
    type: 'DeprecationWarning',
    code: 'stylelint:005',
    detail: 'Please pass a `fix` callback to the `report` utility of "scale-unlimited/declaration-strict-value" instead.'
  }
]

So the monkey-patch should probably be updated to:

if (
- message &&
- typeof message === 'string' &&
- message?.includes(ruleName) &&
  options &&
  typeof options === 'object' &&
+ options?.detail?.includes(ruleName) &&
  options?.type === 'DeprecationWarning' &&
  options?.code?.startsWith(STYLELINT_DEPRECATION_WARNING_PREFIX)
) {
  return;
}

// Or, for retro-compatibility, something like :
// 
// if (
//   message &&
//   typeof message === 'string' &&
//   options &&
//   typeof options === 'object' &&
//   options?.type === 'DeprecationWarning' &&
//   options?.code?.startsWith(STYLELINT_DEPRECATION_WARNING_PREFIX) &&
//   (message?.includes(ruleName) || options?.detail?.includes(ruleName))
// ) {
//   return;
// }

[AndyOGo]

Thank you @Donov4n

I just released a fix of the unsafe monkey patch of node's process.emitWarning API as v1.10.8

[flavio-marchi-exxas]

will happen with the next major version of stylelint.

When will this happen? The error still shows today with the latest version.

[AndyOGo]

@flavio-marchi-exxas Please ask questions related to the roadmap of stylelint in their repository. If you use the github search you would not spam this thread and find their project for the next major version 17. https://github.com/stylelint/stylelint/issues/7396