ESLint’s v6.0.0 release, published June 21, 2019, gives teams new ways to shape linting rules across a project—but it also changes existing behavior. For developers maintaining JavaScript code, the practical question is not simply what is new, but which established configurations need attention. [shared-37f9d3ffdb7c37033d1489c22e75c89940ac46de8102c57389f2a0398fc17feb]
Configuration built with glob patterns can now use extends and nested overrides, and projects can use multiple processors. Two rule changes offer narrower controls: function-paren-newline gains a multiline-arguments option, while sort-keys gains minKeys. These additions give maintainers more ways to express project-specific standards without changing the purpose of linting itself. [shared-37f9d3ffdb7c37033d1489c22e75c89940ac46de8102c57389f2a0398fc17feb]
The release also corrects reported behavior in existing rules: no-else-return autofixes could create name collisions; max-len did not properly ignore trailing comments; no-var could incorrectly fix a variable named let; and require-atomic-updates reported parameters. Those corrections matter to people relying on automated checks and fixes, though the announcement provides no measure of time saved. [shared-37f9d3ffdb7c37033d1489c22e75c89940ac46de8102c57389f2a0398fc17feb]
Because v6.0.0 includes breaking changes, the project published a migration guide explaining them and how to upgrade. That is a necessary starting point, not evidence that every team’s transition is effortless. The release notes establish what changed; the remaining question for maintainers is which local configurations and workflows depend on the old behavior. [shared-37f9d3ffdb7c37033d1489c22e75c89940ac46de8102c57389f2a0398fc17feb]