improve eslint config and linting experience #1695
Description
Category
- Plugins
Component
eslint-config
Problem
Our current eslint config is complex and probably not configured correctly. Packages that depend on it do not properly declare their dependencies on the plugins used in the config. Linting all plugins at once (e.g. in CI) is difficult because the error messages are hidden in a bunch of extraneous output.
Proposed solution
Migrate to the new eslint flat config. Set up the configuration at the top-level of blockly-samples so that the repository can be linted at once without needing to use lerna run.
eslint cli
Instead of using the eslint CLI, we have a custom script in dev-scripts that uses the javascript api. I don't know why this is necessary and I think it is probably simpler to use the CLI directly.
eslint flat config
Note that for the below paragraphs, I'll use "eslint plugin" to refer to plugins for eslint. I'll use "packages" to refer to the blockly-samples plugins, to avoid confusion.
The way eslint has historically been configured is via cascading layers of configuration. You can nest configuration files in different directory levels and they'll be merged into one config and run on the appropriate code. Because of this there are limitations in how eslint plugins can be required and shared for shared eslint configs. See this issue for more context. We have a shared eslint config that uses multiple eslint plugins. The blockly packages then declare their dev dependency on the shared eslint config, but they don't declare their dependency on the eslint plugins like they are supposed to. This means that likely the shared config does not work if you try to invoke lint outside of dev-scripts (unless you install the plugins, which we don't tell you about anywhere), and it causes problems because the version number you'll get of those plugins is essentially undefined behavior, since we have an undeclared dependency.
eslint has fixed this by introducing the flat config. Using the new style of configuration, some features like the cascading config have been removed, but in other ways the config has been simplified, such as allowing a shared config to just have a dependency on their plugins, and not require downstream consumers to also require those plugins.
The flat config simplifies deciding what files it applies to. It has a files property that supports globs. This is simpler than today where either you have to specify the current directory and lint everything in it, or carefully specify which files to invoke eslint on the command line.
shared config
Beyond this, I don't think we need a shared config that we publish as a plugin at all. We should be able to change the style of our packages without worrying about if we're making a breaking change to users of our shared config (which we do now, so anyone actually trying to use our config is probably not having a good time). There is not really any point to publishing the config as a blockly plugin because we don't intend for anyone outside of blockly-samples to use it.
If the config were just at the root level of blockly-samples, we could run lint from the root level of samples and lint the entire repository at once without using lerna. This would make lint warnings and errors more obvious on CI.
I believe we could still also lint an individual plugin because the config would be found in the enclosing directory structure, but this needs confirmation.
plugins in core repo
If we move plugins to the main google/blockly repo, this will make even more sense. We'd have one flat config at the root level that applies to both core and plugins. If needed, plugins can have an override with more strict rules than applies to core. This allows us to simplify the eslint setup, make sure the dependencies are correct and consistent, and see all lint messages at once without ever having to set up the shared config.
references