Implementation of Disabled Comments in Markuplint #1079
Replies: 2 comments
-
Disabled Comments ProsI am currently using Markuplint for my Vue components. I have applied the required-attr rule and made sure to specify the "selector": "button",
"rules": {
"required-attr": {
"value": [
{
"name": "type",
"value": ["button", "reset", "submit"]
}
],
}
} However, I encountered an issue recently when creating a new <! -- markuplint does not evaluate the contents of bindings -->.
<button :type="buttonType"> To address this issue, we decided to specify a specific "selector": "button:not([data-markuplint-disable])", <button :type="buttonType" data-markuplint-disable> While this may be a vue-parser evaluation issue, I believe it would be more convenient to disable comments instead of specifying selectors, allowing us to ignore the target while still preserving the intent in the source. |
Beta Was this translation helpful? Give feedback.
-
I need disable comments. 🥺 The case of ESLint and TypeScript in our projectESLint and TypeScript have comment features to disable errors. When I introduce ESLint to an existing project, I can disable errors and warnings by adding Example: // eslint-disable-next-line eqeqeq -- FIXME: Disabled this when introducing the rule
if (a == b) console.log("sample"); Then, we planned to fix the errors gradually when touching the code and follow the rules for new code. We did the same for tsconfig by changing As a result, the quality of our TypeScript code gradually improved. When writing new code, we were able to follow the rules. Benefits of Specific Disable Comments for RulesWhen resolving previously disabled errors, there were benefits to specifying the rule name in the disable comments. Being able to search within the repository allowed us to address errors caused by specific rules across multiple files collectively. Among linter rules, some are easier to fix than others. For example, in ESLint, the In the case of Markuplint (without disable comments)But with Markuplint, I can't use this approach, so I haven't been able to introduce it yet. 😢
I know that Markuplint has such a feature, but it affects the published HTML. I respect the intention of not wanting to create code deterioration. However, I want to create an environment to improve the markup, even if it requires some compromises. Ideas to prevent the misuse of disable commentsTo prevent the misuse of disable comments, I believe it is essential to have an option that requires writing a description (a reason). ESLintThere is a plugin for eslint comments, which has a rule to require a description when using disable comments. TypeScriptThere is a rule to require a description when using StylelintThere was a rule to require a description when using disable comments. But it was removed. Now, there is an option to report the descriptionless disable comments. |
Beta Was this translation helpful? Give feedback.
-
I am considering implementing 'disabled comments' in Markuplint and would like to discuss the pros and cons of such a feature.
While I understand that disabled comments are commonly used when gradually increasing the scope of linters, I'm reluctant to promote their introduction actively. My concern stems from the belief that disabled comments could potentially act as a source of "broken windows", meaning they could encourage neglect and a gradual decline in code quality. A file's use of disabled comments can't be discerned until it is opened and inspected, making it difficult to maintain consistent code standards.
However, Markuplint already provides an alternative to disabled comments with the ability to control the scope of rules via selectors. This should offer sufficient flexibility for users to manage the application of linting rules to their code.
If we were to implement disabled comments, I suggest they should be disabled by default. Users could then enable them if necessary through configuration files or CLI options. By making the usage of disabled comments explicit in the config file, it allows the use of this feature to be shared with collaborators more transparently.
As the author of a linter, I'd like to emphasize that introducing a linter into an organization requires a strong commitment to maintaining high code quality. I welcome everyone's feedback on this matter.
Beta Was this translation helpful? Give feedback.
All reactions