Goal: Apply ESLint consistently throughout portal — by having a centrally managed configuration that is applied everywhere, developers will automatically obtain a workflow that produces higher-quality results and cuts down on noise in code review.
With the move from the previous frontend csf (which lints and formats) to prettier (which only formats), we necessarily need to integrate ESLint as well. The idea is that "prettier + ESLint" covers the same territory as csf.
Previously we have used ESLint in portal in limited or isolated ways.
However, ESLint is likely to produce a lot more warnings and errors than csf because it has a huge number or rules turned on in the "recommended" preset, which our own eslint-config-liferay extends. It's true we can turn off rules, but they are "recommended" for a reason: they tend to catch legitimate smells and patterns that can potentially lead to problems further down the track.
My initial proposal here is that we update liferay-npm-scripts to provide a new command for running ESLint in a kind of "soft" mode.
- We'll run it manually at first to gauge the scope of the lint issues exposed; it may be that I am overestimating the size here and it ends up being trivial to fix them all.
- However, if there are a lot of lint issues, we'll create tickets for code owners to address the new lints that this tool reports. We can also get the ball rolling by addressing some of the lints themselves.
- Once the issue count is low enough to integrate this in the build without turning it into an avalanche of lint messages, we integrate it.
- We gradually tighten things up until we can transition from "soft" to "hard" linting, which means that the lints will be fully automated and treated as errors instead of just warnings.
- Along the way we'll need to add some custom lints for things that we've identified as enforcement worthy; things like LPS-96488 (file naming),
LPS-96486(using new sidenav API instead of legacy), LPS-96485 (using new fetch API instead of bare fetch) etc.