Start with the type-checked recommended preset for a Node service, and move to strict type-checked once the team is comfortable. The type-checked presets need type information, which costs lint time, but they enable rules such as the one that finds unhandled promises. Plain recommended does not.
The four presets
The typescript-eslint documentation describes them like this:
| Preset | Needs type info | What it is |
|---|---|---|
| recommended | No | Rules for correctness, almost always a bad practice or likely bug |
| recommended-type-checked | Yes | Everything in recommended plus rules that use type information |
| strict | No | Recommended plus stricter, more opinionated rules |
| strict-type-checked | Yes | All of the above plus strict rules that use type information |
The docs say strict is best when a meaningful share of developers are highly proficient in TypeScript, and that strict configs are not covered by semver stability, so rules can change outside major releases. Pin the plugin version and read release notes.
Why type information matters here
Rules that read types can see what a value really is. The no-floating-promises rule, for example, needs types to know that a call returns a promise. Without type information it cannot work, and the docs say it is enabled by recommended-type-checked. A forgotten await on a permission check is a real security bug, because the check never gates anything.
Setup in flat config
The docs show a typed setup like this:
import js from '@eslint/js';
import { defineConfig } from 'eslint/config';
import tseslint from 'typescript-eslint';
export default defineConfig({
files: ['**/*.{js,ts}'],
extends: [js.configs.recommended, tseslint.configs.recommendedTypeChecked],
languageOptions: {
parserOptions: { projectService: true },
},
});
The docs point to their typed linting page for the full setup, so check it for your project layout.
A rollout path
- Add recommended-type-checked and fix errors, or mark the noisy ones as warnings for a sprint.
- Make lint a required CI check so findings cannot pile up.
- After a month, try strict-type-checked in a branch and count new findings.
- Adopt the strict rules that catch real bugs for you, and turn off the ones that only add noise.
- Never disable a rule inline without a comment saying why.
What linting does not replace
Lint rules in this family target correctness. They are not a vulnerability scanner. They will not flag a vulnerable dependency, and they do not trace tainted data from a request to a sink. For the split between linting and scanning, see SAST for JavaScript and TypeScript: linter or scanner.
Try it yourself
Open the code scan demo and compare what a scan finds with what a linter would. Notice the findings that depend on data flow.
Click through it at your own pace, or open it full screen.
Safeguard covers dependency scanning and reachability analysis, which is the part lint rules cannot do. You can start with a free scan.
Quick check
Does the plain recommended preset include no-floating-promises?
No. The docs say that rule needs type information and is enabled by recommended-type-checked.
Is the strict preset stable across minor releases?
Not guaranteed. The docs say strict configs are not covered by semver stability.
Sources
Last reviewed: 19 October 2026.
