JS Party: JavaScript, CSS, Web Development · Changelog Media

Going flat with ESLint

July 25, 2024·1 hr 21 min·2 clips

ESLint's flat config represents a paradigm shift in linting configuration

Josh Goldberg works as a full-time independent open source maintainer with funding from multiple projects, including TypeScript ESLint (core maintainer), Mocha (maintenance team), and ESLint (committer). In this conversation on JS Party, he explains the transition from the legacy ESLint RC config format to flat config. The legacy system had several confusing properties: nested config files across monorepos made it difficult to reason about which rules applied to which files; overrides within a single file created a second layer of complexity; and plugins were referenced by string aliases rather than by actual module imports, meaning the resolution system was a near-but-not-quite replica of Node's require algorithm. The new flat config addresses all of these: a single exported array is the only config, actual imports replace string names, and the behavior is much more predictable. ESLint v9 shipped with flat config as the default, but the rollout caught many developers off guard — partly because people don't actively follow ESLint announcements, and partly because the ESLint team was late in reaching out to plugin maintainers who also needed to migrate. This mismatch meant that users upgrading to v9 found their plugins not yet supporting flat config, triggering confusion and frustration. Josh discusses why it matters to communicate not just what is changing but why — the case for flat config requires explaining the real pain points of the old system, especially for large monorepo codebases where the resolution edge cases compound. He also discusses his work migrating DefinitelyTyped from TSLint to ESLint and from Prettier to dprint (a Rust-based formatter that is significantly faster at the scale of DefinitelyTyped's tens of thousands of files and TypeScript's 50,000-line checker.ts).

As heard by us

A practical ESLint discussion about rules, exceptions, and making team decisions visible.

JS Party treats ESLint as a matter of judgment rather than dogma, with Nick Nisi, Boneskull, and Josh Goldberg returning to one practical rule: most lint checks should hold the line, and when a team needs to turn one off, the reason belongs right beside the exception in the…

Read the full review in PlayNext →

Why you'd press play

You want a calmer way to handle lint exceptions without hating the linter.

Read the full recommendation in PlayNext →

Listen to the show on

Apple Podcasts Spotify

Play clips from this episode More from JS Party: JavaScript, CSS, Web Development