edge / eslint-config-typescript Goto Github PK

With the removal of the curly rule in 0.1.2, we should check whether the very long lines quirk still applies, and update the README based on current outcomes.

Currently, TypeScript is ahead of the supported versions. I don't think this is much of an issue, but the output is a bit noisy.

WARNING: You are currently running a version of TypeScript which is not officially supported by @typescript-eslint/typescript-estree.

You may find that it works just fine, or you may not.

SUPPORTED TYPESCRIPT VERSIONS: >=3.3.1 <4.4.0

YOUR TYPESCRIPT VERSION: 4.4.2

Please only submit bug reports when using the officially supported version.

We can suppress this with

"parserOptions": {
    "warnOnUnsupportedTypeScriptVersion": false
  },

What are your thoughts on this?

Vue 3 projects created with npm init vue@latest include an ESLint setup that works with Vue SFCs.

Augmenting the base ESLint rules (which are fairly relaxed) with our own requires copy-pasting the rules and overrides in the ESLint JSON in this package, because plugin:@typescript-eslint/recommended does not support Vue SFCs and considers them all erroneous.

It would be nice to have a way to determine whether the project is a Vue project automatically and if so, extend it safely, without compromising the existing rules for backend use.

There seems to be a Kobayashi Maru with regard to import sort ordering.

I think we should disable nonblock-statement-body-position.

It's caused no end of frustration over the past few months, and while the idea that it stops people doing this...

if (condition)
  doSomethingOnlyIfCondition()
  thisWillHappenEitherWay()

...is valid, I don't think I've ever actually come across that. As it stands, there are if statements that are either so long that we have to disable the line length rule (to use beside) or we have to write more code just to satisfy multiple lines and a curly block.

I'm currently making use of /* eslint-disable nonblock-statement-body-position */ but I sincerely believe this rule is causing more trouble than it is worth.

Is this something you could pick up and push out when you have a spare moment @annybs?

(p.s. labels on this repo! 😰 they're default)

https://eslint.org/docs/rules/no-unused-vars#args

We need to agree on what basis to disallow unused function parameters via the no-unused-vars rule.

The after-used default setting should already be in effect as we extend the recommended ruleset, but a quick test in my editor suggests that is not the case. We may need to manually enable the superset rule @typescript-eslint/no-unused-vars to provide this coverage. (see)

Additionally, we should clarify whether we are satisfied with the after-used rule, or if we should be more aggressive and go with all thereby requiring all parameters to be used without exception. Of course, we can disable this case-by-case if it causes any issues. It's just nicer to not have to.

At the moment, the maximum line length max-len is soft limited to 120 characters:

I think we should increase this, particularly to allow longer single-line statements, conditionals, and deeper indentation (which is sometimes unavoidable). It may also help when writing Vue templates.

I propose increasing the limit to 160, which would fit code like the following a bit better:

const readBody = validate.validate<Data>({
  referralCode: validate.seq(validate.optional, validate.str, validate.exactLength(config.accounts.referral.codeLength))
})

(As shown this is 121 chars but in the actual code there is more indentation!)

Additional actions: if approved and changed, we need to make the same change in the JS config.