Refactor to add message types to the core rules that pass message arguments to report
#8294
Conversation
|
Mouvedia
changed the title
messages typesmessages types to core rules that pass messageArgs to report
Mouvedia
force-pushed
the
mouvedia-crm-6
branch
2 times, most recently
from
b602588 to
ed54f95
Compare
| { | ||
| expected: (expected: string, actual: string) => string; | ||
| rejected: (keyword: string) => string; | ||
| } |
There was a problem hiding this comment.
messageArgs wasn't added to rules that require for the user to check the arity.
e.g.
message: (a, b) => {
if (typeof b === 'string') {
/* … */
} else { /* … */ }
}
It may be added so that #6966 can be resolved but that's out of scope for this PR.
The main rationale behind the type's addition is that it can eventually flow to message.
i.e. not for messages itself (for that we have the Messages default)
Since color-named has the arguments backward for AutofixMessage that's a blessing in disguise.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
Mouvedia
changed the title
messages types to core rules that pass messageArgs to reportCoreRules type to add messages types to the rules that pass messageArgs to report
|
This PR is packaged and the instant preview is available (b085634). View the demo website. Install it locally: npm i -D https://pkg.pr.new/stylelint@b085634 |
Mouvedia
changed the title
CoreRules type to add messages types to the rules that pass messageArgs to reportreport
…uments to `report`
|
@ybiquitous I have simplified the types, please take a look when you will have the time. |
| 'media-feature-name-unit-allowed-list': CoreRule< | ||
| Record<string, OneOrMany<string>>, | ||
| {}, | ||
| RejectedMessage<[unit: string, name: string]> |
There was a problem hiding this comment.
note
should be [name: string, unit: string] but that would be a breaking change
2 participants
#8239
This PR won't touch the rules.
i.e. the erroneous messages and/or badly named parameters can be corrected in followup PRs
The medium term goal would be to flow the type to
messageso that it may eventually be exploited by your IDE when using js/mjs/cjs configs.It can already be achieved through other means though.
e.g. https://github.com/search?q=repo%3Astylelint-types%2Fstylelint-define-config+message%3F&type=code