ESLint’s June 21, 2019 release changes how teams can organize linting as well as what an upgrade may require. Glob-pattern configurations can now use extends and nested overrides, and projects can use multiple processors. That gives maintainers more ways to divide configuration across files and tools; it does not make those arrangements costless to understand or maintain. [shared-37f9d3ffdb7c37033d1489c22e75c89940ac46de8102c57389f2a0398fc17feb]
Two rule options add narrower choices: function-paren-newline gains multiline-arguments, while sort-keys gains minKeys. For teams with established lint policies, the practical question is whether those controls fit existing conventions—not whether more settings automatically improve code. Multiple processors may broaden tool compatibility, but the release announcement does not quantify adoption or performance effects. [shared-37f9d3ffdb7c37033d1489c22e75c89940ac46de8102c57389f2a0398fc17feb]
The release is explicitly major and includes breaking changes; ESLint points users to a migration guide describing those changes and how to upgrade. Its listed fixes also address concrete edge cases: no-else-return autofixes that caused name collisions, max-len handling of trailing comments, no-var fixes involving variables named let, and require-atomic-updates reports on parameters. The test of the release is therefore two-sided: do the new configuration choices help teams, and can they absorb the compatibility changes? The announcement alone cannot show how much migration work any particular project faces. [shared-37f9d3ffdb7c37033d1489c22e75c89940ac46de8102c57389f2a0398fc17feb]