refactor fixers of selector-not-notation and function-name-case

[Mouvedia]

Which issue, if any, is this issue related to?

#2643

Is there anything in the PR that needs further explanation?

Most of the rules won't require as much work as selector-not-notation to transition.
That's why I have chosen to refactor a simpler rule to demonstrate how easy it could be.

This PR unlocks #7192 and #4664.

selector-not-notation now reports new line ranges correctly

function-name-case reports the full name instead of the first letter previously

see #7706 (comment)

tests can be found here: c162413 (#7729)

TODO

• stylelint-disable
• stylelint-disable-line
• stylelint-disable-next-line
• stylelint-* foo-bar
• stylelint-* foo-bar, qux-baz
• add changeset
• ignoreDisables
• create experimental branch
  • revert to unsafe behaviour
  • update stylelint.utils
  • add tests

[changeset-bot]

🦋 Changeset detected

Latest commit: 276cdfa

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
stylelint	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[Mouvedia]

@romainmenke @ybiquitous
Concerning

We can either

• keep the safe behaviour introduced in v13.2.0 until all rules are migrated
• revert to the v13.1.0 unsafe behaviour
• or create a long-lived experimental branch

I would like to have your opinions.
Depending on this decision Ill have to make a few more changes to this branch.
FYI there are 33 fixable rules.
cf 49b343a

[Mouvedia]

minor
questions

@romainmenke
Why do I need + 1 here?
Is this a bug?

[Mouvedia]

@romainmenke @ybiquitous Concerning

We can either

• keep the safe behaviour introduced in v13.2.0 until all rules are migrated
• revert to the v13.1.0 unsafe behaviour
• or create a long-lived experimental branch

I would like to have your opinions. Depending on this decision Ill have to make a few more changes to this branch. FYI there are 33 fixable rules. cf 49b343a

Thinking about it more, I think a mix of the 3 is possible.

1. add 33 tasks to Add stylelint-disable commands support to autofix  #2643 and convert to type umbrella
2. create experimental branch: refactor-autofix-disable
3. add first 2 refactors to the main branch (this PR)
4. add tests (experimental branch)
5. revert Disable fixing files if fixing can cause bugs #4573 (experimental branch)
6. add a new --safe-disables to accommodate plugin rules (experimental branch)
7. add refactors one by one
8. once all the rules have transitioned merge the experimental branch

For the users it's transparent and the migration will be smoother.
I am gonna make the necessary changes to this branch accordingly.

tl;dr: tests on refactor-autofix-disable, refactors on main

[ybiquitous]

@Mouvedia Thanks for working on old issues! I'm still reading the code, but I've left a few comments for you to address.

[ybiquitous]

I'm reading the code in this PR, but this seems related to endColumn in PostCSS API: ⬇️

Column for exclusive end position in the input file with this warning’s source.

https://github.com/postcss/postcss/blob/f9a9868eb3a591cd99d504ac57bf7ee77380856b/lib/warning.d.ts#L67

---

The following test code:

import postcss from 'postcss';
import selectorParser from 'postcss-selector-parser';

const print = ({ start, end }) => {
	const { line: sLine, column: sCol } = start;
	const { line: eLine, column: eCol } = end;
	console.log('start: %o, end: %o', { line: sLine, column: sCol }, { line: eLine, column: eCol });
};

console.log('.abc {}');
console.log('1234567');
console.log('---');

print(postcss.parse('.abc {}').nodes[0].source);
print(selectorParser().astSync('.abc').nodes[0].nodes[0].source);

prints below: ⬇️

.abc {}
1234567
---
start: { line: 1, column: 1 }, end: { line: 1, column: 7 }
start: { line: 1, column: 1 }, end: { line: 1, column: 4 }

It seems that postcss and postcss-selector-parser are consistent for source positions.

[Mouvedia]

I have rebased on main due to #7722.

[romainmenke]

Thank you for taking up this effort @Mouvedia!

I have one concern with this change and that is that it seems to defer the fixes.

Is that correct?

The order of execution seems to change to roughly:

• lint source with Rule A
• capture fixes for Rule A in a callback
• lint source with Rule B
• capture fixes for Rule B in a callback
• lint source with Rule C
• capture fixes for Rule C in a callback
• ...
• apply fixes for Rules A, B, C, ...

While the current order of execution is roughly :

• lint source with Rule A
• apply fixes for Rule A
• lint source with Rule B
• apply fixes for Rule B
• lint source with Rule C
• apply fixes for Rule C
• ...

This change means that we have to define what happens in these scenario's and add sufficient test coverage:

• two rules mutate the same AST node
• a rule mutates an AST node that has since been removed
• a rule inserts a new node and this new node can be autofixed by another rule (e.g. insert :not() and something else enforces allcaps :NOT(), not sure if we have such conflicts, but they will definitely exist)
• ...

[Mouvedia]

I have one concern with this change and that is that it seems to defer the fixes.

Is that correct?

The order of execution seems to change to roughly:

• lint source with Rule A
• capture fixes for Rule A in a callback
• lint source with Rule B
• capture fixes for Rule B in a callback
• lint source with Rule C
• capture fixes for Rule C in a callback
• ...
• apply fixes for Rules A, B, C, ...

While the current order of execution is roughly :

• lint source with Rule A
• apply fixes for Rule A
• lint source with Rule B
• apply fixes for Rule B
• lint source with Rule C
• apply fixes for Rule C
• ...

This change means that we have to define what happens in these scenario's and add sufficient test coverage:

• two rules mutate the same AST node
• a rule mutates an AST node that has since been removed
• a rule inserts a new node and this new node can be autofixed by another rule (e.g. insert :not() and something else enforces allcaps :NOT(), not sure if we have such conflicts, but they will definitely exist)
• ...

I have tested one of your scenarios. You are completely right; this is an obvious oversight.
I have got an idea on how to cover these cases but it involves a different approach.
Ill open a new PR once I am done experimenting: #7730