Add `named-grid-areas-alignment` rule

[Maxim Morev]

What is the problem you're trying to solve?

Hello, first of all thank you for your work :)

I've been thinking for quite some time about a rule that would format the grid-template-areas value into a table, illustrated:

Input:

.block {
  grid-template-areas:
    'column another another . a d'
    'column foo foo . e .'
    'longest-one foo foo . bar bar';
}

Output:

.block {
  grid-template-areas:
    'column       another  another  .  a    d'
    'column       foo      foo      .  e    .'
    'longest-one  foo      foo      .  bar  bar';
}

From experience, this can dramatically improve readability.

What solution would you like to see?

I could implement this rule in the scope of this package, if you're interested.
In that case, we can discuss options and edge cases here.

If you want to keep the package only for rules that were originally in Stylelint - no problem, I'll make a separate plugin for that :)
By the way, ESLint Stylistic already introduced few new rules in addition to ESLint's original stylistic rules.

What are your thoughts on this?

[firefoxic]

@MorevM Thanks for the proposal.

If you want to keep the package only for rules that were originally in Stylelint

No, the plugin should not be a frozen form of the rules removed from Stylelint. Additions and enhancements are welcome!
Perhaps we should be more explicit about this, not just with this short sentence.

I could implement this rule in the scope of this package, if you're interested.

Thank you!!! That would be great!

I've labeled the issue as ready to implement. Please check out CONTRIBUTING.md.
There are steps on how to add a new rule in the Developer guide.

[firefoxic]

It seems that the name of the new rule should start with named-grid-areas- for consistency with the upstream rule named-grid-areas-no-invalid. But the ending needs some thought 🤔

[firefoxic]

In this example, the column gap is 2 spaces:

.block {
  grid-template-areas:
    'column       another  another  .  a    d'
    'column       foo      foo      .  e    .'
    'longest-one  foo      foo      .  bar  bar';
}

Perhaps we need an option to control the size of this gap.

And about closing quotes — should they be aligned in a column? E.g. like this:

.block {
  grid-template-areas:
    'column       another  another  .  a    d  '
    'column       foo      foo      .  e    .  '
    'longest-one  foo      foo      .  bar  bar';
}

[Maxim Morev]

I would like to see this named named-grid-areas-table-alignment (or even just named-grid-areas-alignment) name with true as a primary option, and an object of form { spacesBetween: number; trailingSpaces: boolean; quotes: 'single' | 'double'; newline: 'never' | 'always' | 'always-multiline' } as a secondary option. What do you think?

Also, we need to decide what to do with invalid values, example:

.block {
  grid-template-areas:
    'foo  bar'
    'bar  foo';
}

Technically, this is invalid property value, but that doesn't prevent from formatting the rows as a table.

I would make the rule format the value regardless of its validity - after all, there is a named-grid-areas-no-invalid rule for that.
If I implement the validation inside a new rule, the old one will be completely absorbed and become useless, and the code of this rule will become much more complicated (which I would like to avoid). But willing to hear an alternative opinion :)

[firefoxic]

I would like to see this named named-grid-areas-table-alignment (or even just named-grid-areas-alignment) name with true as a primary option

Although I don't have experience with adding new rules yet, the second variant looks more in line with the naming rules.

spacesBetween: number;

Another possible variant is columnGap: number;.

trailingSpaces: boolean;

Another possible variant is quotesAlign: boolean;.

quotes: 'single' | 'double';

There is already a separate rule for selecting quotes. In this rule, quote control will be unnecessary.

newline: 'never' | 'always' | 'always-multiline'

There are separate rules for this as well. As far as I can remember, several rules work well together. It seems that in this rule it's enough to just check: if the value is one row, it doesn't need to be formatted in any way, because there are no columns to align.

we need to decide what to do with invalid values

No, in a plugin it's better to check only the styling and not the syntax, especially since Stylelint already has this rule and works well.

[Maxim Morev]

Yeah, I overthink this :)
Just checked that string-quotes and declaration-colon-newline-after handle such cases well.

I would suggest stopping at the options form like { gap: number; alignQuotes: boolean; }.
Is it ok for you?

if the value is one row, it doesn't need to be formatted in any way

It does not conflict with gap, preventing values with mixed gap such as 'a b c .'

[Maxim Morev]

@firefoxic

Hi, I'm pretty busy but I'm taking a little time on weekends to do this, I think it will be ready for review/release in 1-2 weeks.

I have one more topic to discuss: message texts and report range.

Technically, we could highlight the position of the first gap other than the one set in the config with the text "Expected {gap} spaces between cells", or highlight the position of the first unaligned quote if alignQuotes is set to true, with the text "Expected quotes to be aligned".

Alternatively, we can highlight the entire value with the text "Expected grid-template-areas value to be aligned".

The first option is more compatible with the Stylelint ideology, but it is more difficult to implement, and given the presence of autofix, I have a feeling like "I don't care where exactly I made a mistake, just format it right".
For personal use I'd probably go for the second option, but I'll take your opinion here as well.

What are your thoughts on this?

[firefoxic]

I apologize for my long absence.

I would suggest stopping at the options form like { gap: number; alignQuotes: boolean; }.

Sounds good!

It does not conflict with gap, preventing values with mixed gap such as 'a b c .'

Yes, I agree.

given the presence of autofix, I have a feeling like "I don't care where exactly I made a mistake, just format it right".

I completely agree. Pointing out the exact location and detailing the configuration mismatch will only add to the complexity of the rule code and its tests. A more general message about the need to align columns will be even clearer than the number of expected spaces.

The same goes for quotes. Although their alignment option can be implemented later, it seems more important to solve the problem with columns.