suggestion: add config flag to deno lint and deno fmt

[DjDeveloperr]

EDIT: It was added in v1.14 🎉

Hi!

I was reading through #dev-lint (Discord Channel) conversation. This is about adding config flag to deno lint and deno fmt.

Honestly having a config isn't bad, actually our deno project still depends on Node. Why? we're using eslint because deno lint cannot be configured the way we want. We have to use prettier because deno fmt cannot be configured and the default style is not what we want it to be.
In my opinion, it would have been way straightforward if deno lint and deno fmt supported config - no need to use external tooling, deno ships with it.

I read through #3827 too, nothing reasonable I could find.

I'm not able to understand the reason for not adding config. It's just optional, use it if you want, not otherwise..

P.S: Its just a suggestion, I don't want to bring up any argument or something.

[lucacasonato]

What exactly do you want to configure?

[lucacasonato]

Can you be more specific about what rules you want to disable for the linter?

[DjDeveloperr]

camelCase, require-await, no-inferable-types mostly.

[Soremwar]

@DjDeveloperr Not using await in an async function is kinda pointless to be fair. And why would you want to have redundant types in your code anyway? Doesn't that increase the length of your code pointlessly?

As for removing camelCase +1 for that. No code should be flagged as incorrect just cause it uses one pretty name over another

PD: Not trying to spark any discussion, just arguing that (excluding camelCase) deno-lint has really good defaults.

[DjDeveloperr]

@DjDeveloperr Not using await in an async function is kinda pointless to be fair. And why would you want to have redundant types in your code anyway? Doesn't that increase the length of your code pointlessly?

As for removing camelCase +1 for that. No code should be flagged as incorrect just cause it uses one pretty name over another

PD: Not trying to spark any discussion, just arguing that (excluding camelCase) deno-lint has really good defaults.

You’re right. camelCase is mostly bothering me.

I forgot to mention about plugins last time, I had to go. What about being able to define custom set of rules using something like plugins? Like in eslint.

[jtoppine]

@DjDeveloperr Not using await in an async function is kinda pointless to be fair. And why would you want to have redundant types in your code anyway? Doesn't that increase the length of your code pointlessly?

In class definitions, I personally consider the async keyword in class methods part of the API design and documentation, or self-documenting code. It immediately tells that the method is meant to be called in async manner, even if the current implementation doesn't.

Say, you have a Cache base class that implements simple non-async in-memory cache, or perhaps has just dummy "no-op" placeholder methods. The cache API is nevertheless designed to be async, so that it can later be extended with async LocalFileCache, S3Cache or whatever specialized truly async implementations. I think it is desireable to have the Cache base class methods also rock the async keyword, and pretty annoying that deno lsp forces one to litter the code with // deno-lint-ignore require-await

[bartlomieju]

This is resolved as of Deno v1.14 https://deno.com/blog/v1.14#customization-options-for-deno-lint-and-deno-fmt