Linter Config

[mateusfg7]

There is a config file of the deno lint? to put all the rules on this file, like a .eslintrc.json.

[magurotuna]

No, currently deno lint is not configurable.
I would say deno lint should be opinionated as much as possible; the more limited users are allowed to configure, the better it would be. It's because if there's no config the linter is usable out of the box, users don't have to worry about how they should tailor the linter for their projects, and all codebase in the Deno ecosystem get equally strict.

That being said, I personally think some configuration system might be necessary. Some people may think they want to disable camelcase rule because they implement API interface with snake_case keys, or other people may want to enable explicit-function-return-type, which is currently disabled by default.
Besides, when it comes to the linter plugin system, configuration gets more required. The plugin system will allow users to create their own lint rules, so which plugin rules should be enabled and where they are imported from have to be configurable.

This topic has been discussed occasionally and really controversial. More opinions/thoughts from lots of Deno users would be really helpful.

ref: denoland/deno_lint#166

[David-Else]

What confuses me is there are 68 'recommend' rules, but 87 rules in total. How do we use the other 20 rules? I have looked at https://lint.deno.land/ and https://github.com/denoland/deno_lint. I must be missing something obvious!

The idea of having a core recommended set of rules that are always on and other rules that are turned on in a config would be great. That way there is a minimum enforced code quality/'deno code style', and people get to add any extras on top of that.

I agree it should be 'opinionated as much as possible', but right now it is missing a lot of fantastic rules I would hope Deno users could agree on. Some of my favourites include:

  "@typescript-eslint/no-unnecessary-condition": "error",
  "@typescript-eslint/no-unnecessary-qualifier": "error",
  "@typescript-eslint/no-unnecessary-boolean-literal-compare": "error",
  "@typescript-eslint/no-unnecessary-type-arguments": "error",
  "@typescript-eslint/no-dynamic-delete": "error",
  "@typescript-eslint/no-throw-literal": "error",
  "@typescript-eslint/prefer-readonly": "error",
  "@typescript-eslint/prefer-readonly-parameter-types": "error",
  "@typescript-eslint/prefer-nullish-coalescing": "error",
  "@typescript-eslint/prefer-optional-chain": "error",
  "@typescript-eslint/prefer-string-starts-ends-with": "error",
  "@typescript-eslint/prefer-ts-expect-error": "error",
  "@typescript-eslint/consistent-type-assertions": "error",
  "@typescript-eslint/consistent-type-definitions": ["error", "interface"],
  "@typescript-eslint/member-delimiter-style": "error",
  "@typescript-eslint/member-ordering": "error",
  "@typescript-eslint/method-signature-style": "error",
  "@typescript-eslint/array-type": "error",
  "@typescript-eslint/switch-exhaustiveness-check": "error",
  "@typescript-eslint/explicit-function-return-type": "error",
  "no-console": "off",

and all the recommended rules that require type checking that can't be implemented yet.

I imagine some people would hate some of them, but some should be universally loved. Ideally there could be a way for users to vote on which rules they like and dislike, just to get an idea of what people feel about them. The final say should of course go to the core devs.

[magurotuna]

How do we use the other 20 rules?

They are not available at all in the current deno lint integrated with Deno CLI. If you'd like to use the "not recommended" rules, standalone dlint binary works for you, which is provided as an example of denoland/deno_lint. Note that "not recommended" rules are not maintained as much as the recommended ones, so probably prone to false positives/negatives.

But this binary is intended to be for testing or prototyping, so I think CLI-integrated deno lint still needs to be configurable in some way.

Ideally there could be a way for users to vote on which rules they like and dislike, just to get an idea of what people feel about them.

Sounds good. As one of the developrs of deno_lint, I truly want to know what people think about for the current rule set. Some people raised issues about it to the deno_lint repo or discussed it on Discord, but thoughts from more people would be much appreciated.