All code should pass TypeScript type checking.

- Comment on a closed PR

- Reasoning: It is much easier for maintainers to not lose track of things if they are posted as issues. If you think there's a bug in typescript-eslint, the right way to ask is to [file a new issue](https://github.com/typescript-eslint/typescript-eslint/issues/new/choose). The issue templates include helpful & necessary practices such as making sure you're on the latest version of all our packages. You can provide the link to the relevant PR to add more context.

Once your changes are ready, you can raise a PR! 🙌

The title of your PR should match the following format:

Once the feedback is addressed, and the PR is approved, we'll ensure the branch is up to date with `main`, and merge it for you.

If you need help and/or have a question, posting a comment in the PR is a great way to do so.

<a href="https://github.com/typescript-eslint/typescript-eslint/pull/6976">

#6976

</a>

</td>

</tr>

<tr>

<a href="https://github.com/typescript-eslint/typescript-eslint/pull/6780">

#6780

</a>

</td>

</tr>

<tr>

<a href="https://github.com/typescript-eslint/typescript-eslint/pull/6107">

#6107

</a>

</td>

</tr>

<tr>

<a href="https://github.com/typescript-eslint/typescript-eslint/pull/6084">

#6084

</a>

</td>

</tr>

</tbody>

In parallel to the shared config changes work, make sure to test out the beta version on popular community projects willing to try it out.

- Ask each community project if they'd be interested in trying out the new version, such as in their Discord or on their issue tracker.

- Each community project that's indicated willingness to receive a PR should have one.

1. Once the proposed _Shared Config Changes_ are merged into the `v${major}` branch, send a draft PR to each project with the new beta version.

</TabItem>

</Tabs>

- If you **do** want to lint the file with [type-aware linting](../getting-started/Typed_Linting.mdx):

- Check the `include` option of each of the TSConfigs that you provide to `parserOptions.project` - you must ensure that all files match an `include` glob, or else our tooling will not be able to find it.

- If the file is a `.cjs`, `.js`, or `.mjs` file, make sure [`allowJs`](https://www.typescriptlang.org/tsconfig#allowJs) is enabled.

<!-- prettier-ignore-end -->

We mirror the ESLint team's move away from _formatting_ and _stylistic_ rules.

With the exception of bug fixes, no new formatting- or stylistic-related pull requests will be accepted into typescript-eslint.

The downside of using a comprehensive formatter for formatting is that it will strictly apply opinions to code.

Some rules also enabled in `recommended` default to more strict settings in this configuration.

See [`configs/strict.ts`](https://github.com/typescript-eslint/typescript-eslint/blob/main/packages/eslint-plugin/src/configs/strict.ts) for the exact contents of this config.

We recommend a TypeScript project extend from `plugin:@typescript-eslint/strict` only if a nontrivial percentage of its developers are highly proficient in TypeScript.

:::

Contains all of `recommended`, `recommended-type-checked`, and `strict`, along with additional strict rules that require type information.

Some rules also enabled in `recommended-type-checked` default to more strict settings in this configuration.

See [`configs/strict-type-checked.ts`](https://github.com/typescript-eslint/typescript-eslint/blob/main/packages/eslint-plugin/src/configs/strict-type-checked.ts) for the exact contents of this config.

We recommend a TypeScript project extend from `plugin:@typescript-eslint/strict-type-checked` only if a nontrivial percentage of its developers are highly proficient in TypeScript.

:::

Rules considered to be best practice for modern TypeScript codebases, but that do not impact program logic.

Many rules conflict with each other and/or are intended to be configured per-project.

:::

A minimal ruleset that sets only the required parser and plugin options needed to run typescript-eslint.

</TabItem>

</Tabs>

This ruleset is meant to be used after extending `eslint:recommended`.

See [`configs/strict-type-checked-only.ts`](https://github.com/typescript-eslint/typescript-eslint/blob/main/packages/eslint-plugin/src/configs/strict-type-checked-only.ts) for the exact contents of this config.

A version of `stylistic` that _only_ contains type-checked rules and disables of any corresponding core ESLint rules.

"ncp": "^2.0.0",

"netlify": "^13.1.14",

"nx": "18.3.5",

"pretty-format": "^29.7.0",

"rimraf": "^5.0.5",

"tmp": "^0.2.1",

JavaScript will call `toString()` on an object when it is converted to a string, such as when `+` adding to a string or in `${}` template literals.

This rule reports on stringified values that aren't primitives and don't define a more useful `.toString()` method.

```ts option='{ "checksVoidReturn": true }'

[1, 2, 3].forEach(async value => {

});

resolve();

});

});

});

const handler = async () => {

await doSomething();

otherSynchronousCall();

<TabItem value="❌ Incorrect">

```ts option='{ "checksSpreads": true }'

};

</TabItem>

<TabItem value="✅ Correct">

```ts option='{ "checksSpreads": true }'

};

</TabItem>

If your project does not attempt to enforce strong immutability guarantees of parameters, you can avoid this rule.

JavaScript automatically [converts an object to a string](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String#string_coercion) in a string context, such as when concatenating it with a string using `+` or embedding it in a template literal using `${}`.

This rule reports on values used in a template literal string that aren't strings, optionally allowing other data types that provide useful stringification results.

:::note

Sorting union (`|`) and intersection (`&`) types can help:

- keep your codebase standardized

<Tabs>