Disable linter rule for a file

[ucheNkadiCode]

In addition to the disable next line, I wanted to propose that it may be a good option for users to be able to ignore a specific linter rule for an entire file.

Requested by @jongio

[jongio]

I have a file that has many lines that need to be ignored. I can now put a disable on every one. Would be nice to just do:

1. once per file
2. once per project - like part of bicep config

[ucheNkadiCode]

@jongio, in your mind, do you think you have different use cases for 1 and 2? Or do you believe that either solution would be sufficient to decrease the line bloat of disabling each line?

I am thinking that giving the user an auto fix to add "disable this warning for the file" at the top of the file, would be as visible and 'per file" as import statements are, which is good for readability/awareness also.

[jongio]

I have a repo with multiple files that have the same warning and I would like to globally disable for the whole project. I don't know how common that would be. If you can only do on file basis then that would work better than only file.

Order of preference:

1. Whole project
2. Whole file
3. Each line

[glennmusa]

I have a repo with multiple files that have the same warning and I would like to globally disable for the whole project. I don't know how common that would be. If you can only do on file basis then that would work better than only file.

Order of preference:

1. Whole project
2. Whole file
3. Each line

Some users prefer disable/enable support for blocks of code too, like in markdownlint:

<!-- markdownlint-disable no-space-in-emphasis -->
deliberate space * in * emphasis
<!-- markdownlint-enable no-space-in-emphasis -->

[ucheNkadiCode]

Note: Add telemetry for which rules are getting disabled at top of file

[ucheNkadiCode]

@StephenWeatherford -> Good idea to add a re-enable line, we'll have to see how much work that is

[ucheNkadiCode]

@jongio and @glennmusa. How does this feature rank in order of preference with these four options? I'll list this out in no particular order

1. Disabling next line (We have this now)
2. Disabling whole project (@jongio, just making sure you're aware we have this via bicep config because your comment seemed as though your first comment was asking for the feature)
3. Disabling for a resource block e.g disable rule 1234 start {resource code...} re-enable rule 1234
4. Disable for file

I'd love to hear your thoughts and any further reasons. Especially as folks that edit in Bicep files pretty often

[glennmusa]

@jongio and @glennmusa. How does this feature rank in order of preference with these four options? I'll list this out in no particular order ... I'd love to hear your thoughts and any further reasons. Especially as folks that edit in Bicep files pretty often

If I had to pick an order of both preference and precedence it'd be:

1. Disabling whole project
2. Disable for file
3. Disabling for a resource block e.g disable rule 1234 start {resource code...} re-enable rule 1234
4. Disabling next line

I think that lines up with how an individual or team might 1) evaluate where specifically they need to change some setting and 2) choose the granularity of that setting, as well as allow for teams of teams to bubble up their settings and concerns to projects and to bicepconfigs.