Add configurationComment configuration property

[ifitzpatrick]

Closes #6628

This PR changes the list of stylelint commands to omit the prefix, and updates functions related to stylelint commands to accept the prefix as an argument. Additionally it makes stylelintCommandPrefix configurable to the users needs.

[changeset-bot]

🦋 Changeset detected

Latest commit: e975776

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

This PR includes changesets to release 1 package

Name	Type
stylelint	Minor

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]

This page will have to be updated.

[ifitzpatrick]

Updated the docs and changed the name of the configuration property to disablesPrefix (#6628 (comment))

[ybiquitous]

Considering we have also stylelint-enable, is the disablesPrefix name suitable? Is commandPrefix (or something else) better?

[jeddy3]

@ybiquitous See #6628 (comment) as disables is consistent with our relevant options. Although, it's not a strong preference.

[jeddy3]

Is commandPrefix (or something else) better?

We may apply this to more than disables and enables in the future, e.g. configuring rules. So, on further thought, maybe there is a better name than disablesPrefix.

ESLint uses "configuration comments" to describe disabling comments too. Should we adopt that terminology for the option name (and internally so that things are consistent)? It's aligned with our language of configuring rules.

The option could be configurationComment, defaulting to "stylelint".

{
  "configurationComment": "foo-stylelint"
}

Internally, we'd change:

• isStylelintCommand(comment) to isConfigurationComment(comment)
• extractStylelintCommand(comment) to extractStylelintComment(comment)
• and so on

We, rather than the user, should add a hyphen before any of our existing command, e.g.:

• const DISABLE_COMMAND = 'disable'; becomes const DISABLE_COMMENT = '-disable';

How does that sound?

[ifitzpatrick]

Is there any concern that changing the names of isStylelintCommand and friends would be a breaking change for rules or plugins outside of this repo?

[ybiquitous]

@jeddy3's idea sounds good to me. 👍🏼

Is there any concern that changing the names of isStylelintCommand and friends would be a breaking change for rules or plugins outside of this repo?

I believe there is no concern because isStylelintCommand is an internal utility, and we have not supported it as a public API.

Just in case, I searched the usage of isStylelintCommand in GitHub, but there seem to be no plugins using the utility.

[ifitzpatrick]

Awesome thanks for looking into that @ybiquitous! Updated those functions and filenames to configurationComment.

[jeddy3]

Thank you for making the changes. It's shaping up nicely.

I've requested a couple of documentation changes and asked one questino.

[jeddy3]

I pushed 3 commits to standardise the terminology elsewhere in our docs as part of this PR.

[jeddy3]

I hadn't realised we had an option related to commands. I think we're ok to move forward with "configuration comment", though, as we have a few other rule secondary options which are at odds with our conventions.

[ybiquitous]

Thank you. LGTM 👍🏼

[jeddy3]

LGTM, thank you.