Linting with type information, also called "typed linting" or "type-aware linting", is the act of writing lint rules that use type information to understand your code. Typed linting rules as provided by typescript-eslint are the most powerful JavaScript/TypeScript linting in common use today.

In this blog post, we'll give a high-level overview of how linting with type information works, why it's so much more powerful than traditional linting, and some of the useful rules you can enable that use it.

typescript-eslint is the tooling that enables standard JavaScript tools such as ESLint and Prettier to support TypeScript code. We've been working on a set of breaking changes and general features that we're excited to get in front of users. And now, we're excited to say that typescript-eslint v8 is released as stable! 🎉

We'd previously blogged about v8 in Announcing typescript-eslint v8 Beta. This blog post contains much of the same information as that one, and includes the list of steps you'll need to take to upgrade.

typescript-eslint is the tooling that enables standard JavaScript tools such as ESLint and Prettier to support TypeScript code. We've been working on a set of breaking changes and general features that we're excited to get in front of users soon. And now, we're excited to say that typescript-eslint v8 is ready for public beta testing! 🎉

Our plan for typescript-eslint v8 is to:

1. Have users try out betas starting in May of 2024
2. Respond to user feedback for the next ~1-2 months
3. Release a stable version within the next ~1-2 months

Nothing mentioned in this blog post is set in stone. If you feel passionately about any of the choices we've made here — positively or negatively — then do let us know on the typescript-eslint Discord's #v8 channel!

We've made some changes to the consistent-type-imports rule to fix some long-standing issues when used alongside experimentalDecorators: true and emitDecoratorMetadata: true. These changes increase safety and prevent invalid fixes when using decorator metadata.

typescript-eslint is the tooling that enables standard JavaScript tools such as ESLint and Prettier to support TypeScript code.

We've been working on infrastructure improvements that will help ensuring long-term interoperability with other tools in the ecosystem. In particular this major release tightens our dependency requirements to help set us up for ESLint v9 and includes a new package typescript-eslint providing full support for flat config files!

Breaking Changes​

This is a small major release with just three breaking changes:

1. Update Node.js engine requirement to ^18.18.0 || >=20.0.0. This means we are dropping support for Node 16, 19, and Node 18 versions prior to 18.18.0. Note that this is the same requirement that ESLint v9 will impose.
2. Update the TypeScript peer dependency requirement to >=4.7.4.
3. Update the ESLint peer dependency requirement to ^8.56.0.

For most users this means that an upgrade from v6 should just look like this:

npm i eslint typescript @typescript-eslint/parser @typescript-eslint/eslint-plugin

yarn add eslint typescript @typescript-eslint/parser @typescript-eslint/eslint-plugin

pnpm add eslint typescript @typescript-eslint/parser @typescript-eslint/eslint-plugin

ESLint recently announced their plan to deprecate their core formatting rules. The ESLint Stylistic project has taken over maintenance of formatting rules.

As a result, we in typescript-eslint are now able to deprecate our formatting rules as well. We'll keep these deprecated rules available until our next major version.

"Typed linting", or enabling ESLint rules to tap into the power of the TypeScript type checker, is one of the best parts of typescript-eslint. But enabling the type checker in repositories with multiple tsconfig.json files can be annoying to set up. Even worse, specifying the wrong include paths could result in incorrect rule reports and/or unexpectedly slow lint times.

Improving the setup experience for typed lint rules has been a long-standing goal for typescript-eslint. One long-standing feature request for that experience has been to support automatically detecting TSConfigs for developers. We're happy to say that we now support that by setting parserOptions.project equal to true in ESLint configurations.

This post will explain what life was like before, what's changed, and what's coming next. 🎉

typescript-eslint is the tooling that enables standard JavaScript tools such as ESLint and Prettier to support TypeScript code. We've been working on a set of breaking changes and general features that we're excited to get released! 🎉

We'd previously blogged about v6 in Announcing typescript-eslint v6 Beta. This blog post contains much of the same information as that one, but updated for changes made since the beta - including a few breaking changes.

typescript-eslint is the tooling that enables standard JavaScript tools such as ESLint and Prettier to support TypeScript code. We've been working on a set of breaking changes and general features that we're excited to get in front of users soon. And now, after over two years of development, we're excited to say that typescript-eslint v6 is ready for public beta testing! 🎉

Our plan for typescript-eslint v6 is to:

1. Have users try out betas starting in early March of 2023
2. Respond to user feedback for the next 1-3 months
3. Release a stable version summer of 2023

Nothing mentioned in this blog post is set in stone. If you feel passionately about any of the choices we've made here -positively or negatively- then do let us know on the typescript-eslint Discord's #v6 channel!

import and export statements are core features of the JavaScript language. They were added as part of the ECMAScript Modules (ESM) specification, and now are generally available in most mainstream JavaScript environments, including all evergreen browsers and Node.js.

When writing TypeScript code with ESM, it can sometimes be desirable to import or export a type only in the type system. Code may wish to refer to a type, but not actually import or export a corresponding value.

Type-only imports and exports are not emitted as runtime code when code is transpiled to JavaScript. This brings up two questions:

• Why would you want to use these type-only imports and exports?
• How can you enforce a project use them whenever necessary?

Let's dig in!