Sometimes developers will use it.only() or describe.only() to run a single jest test locally but accidentally commit it to a PR and thus skip all tests except the one they're working on.

We should probably disable it.skip() as well for the same reason.

When we upgrade ESLint to 8.14.0 we should enable this rule: https://eslint.org/docs/rules/no-constant-binary-expression

I tried enabling it and found two instances of easy to fix bugs.

Saw this recommended in this tweet

We are currently using the default options of this recommended rule @typescript-eslint/no-misused-promises, but it results in errors trying to pass functions that return promises as React props to components that are only expecting a () => void type, including built in React event handlers like onClick.

This fix for this is to update the options for the rule disable checking void returns for attributes like this:

  "@typescript-eslint/no-misused-promises": [
    "error",
    {
      "checksVoidReturn": {
        "arguments": false,
        "attributes": true
      }
    }
  ]

https://github.com/import-js/eslint-plugin-import/issues/2469

Would much prefer

import { type Foo } from 'some/package` 

over

import type { Foo } from 'some/package`

as it keeps the single import line, and all related entries together.

https://github.com/import-js/eslint-plugin-import/pull/2475 looks like it may block this though.

https://github.com/import-js/eslint-plugin-import/blob/main/docs/rules/no-extraneous-dependencies.md

We should also enable the options includeInternal and includeTypes.

As this is now widely supported, we can probably enable this. It's auto-fixable too.

https://github.com/sindresorhus/eslint-plugin-unicorn/blob/main/docs/rules/prefer-node-protocol.md

We see people setting enum keys in const-style sometimes, but would prefer to standardise around the approach used in docs.

This can be set via: https://typescript-eslint.io/rules/naming-convention

Incorrect

enum Colors {
  RED = 'rgb(255, 0, 0)',
  NOT_RED = 'rgb(0, 255, 255)',
}

enum COLORS { /* ... */ }

Correct

enum Colors {
  Red = 'rgb(255, 0, 0)',
  NotRed = 'rgb(0, 255, 255)',
}

See:

• https://www.typescriptlang.org/docs/handbook/enums.html
• https://basarat.gitbook.io/typescript/type-system/enums

We currently hardcode some custom components here, including this copy-paste mistake. https://github.com/vercel/style-guide/blob/canary/eslint/rules/next/jsx-a11y.js#L14

We need to find a more flexible approach to this.

One solution might be to generate an ESLint config via a function.

For consistency in test files, we can consider enabling these rules:

• jest/no-duplicate-hooks
• jest/prefer-lowercase-title
• jest/require-top-level-describe

This has recently been added, and will have some crossover with our current rules: https://github.com/typescript-eslint/typescript-eslint/pull/4706

We could consider exposing this through our own strict config.

The react/jsx-no-useless-fragment has a allowExpressions configuration option that allows fragments that have a single expression in them like:

const arrayOfElements = array.map((item) => {
  return <span key={item}>{item}</span>
})
<>
  {arrayOfElements}
</>

This is useful for TypeScript when in an component you want to return a single array of elements but if you return just the arrayOfElements then the return type of the component becomes JSX.Element[] which when you use the component produces an error:

'Component' cannot be used as a JSX component.
  Its return type 'Element[]' is not a valid JSX element.
    Type 'Element[]' is missing the following properties from type 'ReactElement<any, any>': type, props, keyts(2786)

So wrapping the array with the fragment fixes the type error but causes the ESLint error, so enabling the allowExpressions option allows for this specific use case.

Hi there 👋. I'd like to propose a new preset for Testing Library: @vercel/style-guide/eslint/testing-library

This preset would enable the following plugins:

• eslint-plugin-testing-library with:
  • recommended rules for React
  • no-global-regexp-flag-in-query
  • no-manual-cleanup
  • prefer-explicit-assert
  • prefer-user-event
• eslint-plugin-jest-dom with recommended rules

These plugins would be enabled only on testing files: ['**/__tests__/**/*.[jt]s?(x)', '**/?(*.)+(spec|test).[jt]s?(x)'],

Thoughts? I'd be happy to create a PR to add this new preset.

Today, when copying SVG elements from Figma to React, many of the properties will be in snake case (stroke-width) but in React we need them to be camel case (strokeWidth)

Right now, there's no way to autofix those errors so a lot of time is spent on manually find and replacing on each SVG copied over. I've previously enabled react/no-unknown-property which will auto-fix the SVG errors:

Thanks!

After enabling the @typescript-eslint/explicit-function-return-type rule, we saw lot's of return types added within expressions that already have a required return type, for example:

<btn
  onClick={(): void => onClick()}
>

Typescript will catch this usually which makes the void return type redundant. The rule has this allowExpressions option that allows for not requiring return types in this example that we should look into enabling since it is false by default.

The downside to this rule is it will allow you to skip specifying the return type in functions like map that you might want to only return a single type from.

As of the latest release, we've unpinned version dependencies.

This gives users more flexibility, and makes it easier to bump dependencies of this package (like @typescript-eslint) to support new TypeScript versions, etc.

This also introduces the risk of a plugin releasing a change to a recommended config in a minor release, which would be breaking as code that previously passed may now fail. Worse, a rule could be broken/removed in a minor release, breaking the config. We feel these risks are very low, which is why we opted to shelve this work for future.