The no-slow-types rule cannot be selectively ignored like other rules

[bradenmacdonald]

Version: deno 1.41.1

The no-slow-types linter rule cannot currently be ignored on a per-file or per-line basis. Doing so gives an error: Unknown rule for code "no-slow-types".

However, putting lint.rules.exclude: ["no-slow-types"] into deno.json does make the linter ignore it for the whole project.

[dsherret]

It can't be selectively ignored because it's an all or nothing feature. If a single instance of slow types is found in a package then it will not do optimizations to make things faster (which can be significant). So if you could ignore the rule in one place then it's not using the optimizations for the package.

However, putting lint.rules.exclude: ["no-slow-types"] into deno.json does make the linter ignore it for the whole project.

If developing a jsr package, you'll need to do this and publish with--allow-slow-types if you wish to disable this rule.

Also, that scenario with Object.freeze looks like something where the types could be inferred. I'll look into it. Also it would be nice if deno gave a better warning in this case.

Edit: Ah, I see jsr-io/jsr#155 now

[bradenmacdonald]

I kind of suspected that might be the reason. If you want to stick with that, I would suggest that a more clear error message would be helpful: something like "this rule can't be ignored on a per-line or per-file basis", rather than "Unknown rule" which is confusing because clearly it is a known rule.

However, I do still think there is a use case for selectively ignoring this rule now. It's a new linter rule and currently somewhat incomplete / buggy. So I'd like to be able to temporarily ignore issues like the example shown, while still fixing the valid occurrences elsewhere in the codebase. That way, my deno lint CI check will pass and the linter will ensure that new slow types problems won't be introduced - currently I have to choose one or the other. For the purposes of JSR, there is still a separate and complete check that happens during deno publish which doesn't take into account the deno lint ignore rules (I assume?).

Not a huge deal though :)

[dsherret]

Opened a second issue to make this more clear: #23182