Fully embrace ESLint stylistic with more deterministic rules

[alcpereira]

All the repos of webdriverio, that I worked with, relies on ESLint (and some with .editorconfig) to format the files.

While this is a good way to enforce style consistency, there are still some gaps between the IDE formatting fallbacks and the present config.

This could be solved with 3 fixes:

• Adopt the full set of rules from @stylistic/eslint-plugin with customize() for example (docs)
• Adopt .editorconfig or other tools in all the repos (out of scope of webdriverio/eslint) for files that cannot be handled by ESLint (JSON, yaml, markdown, etc)
• Document it in CONTRIBUTING.md of the repos: for example configure your IDE to run ESLint last (after Prettier or Biome for example)

If a maintainer can try a pre-release with a complete set of rules from @stylistic/eslint-plugin to measure the impact and adapt it accordingly 🙏

[christian-bromann]

This all sounds great to me. I would love to consolidate all styling within Eslint in favor of introducing an additional tool like prettier for it. .editorconfig is something that works great when the right extension is installed. We can maybe also add an .vscode/extension.json file in all repositories.

[YasharF]

I think it would be good to adjust things so the order in which ESLint, Prettier, etc. run does not matter — in other words, configure them so they don’t have conflicting rules. Here’s what I propose:

1. (optional) .editorconfig for basic configs like indentation size, end‑of‑line, etc.

2. Prettier as the owner for formatting (wrapping, semicolons, quotes, trailing commas, object/array spacing)
   2a. Mostly use defaults.
   2b. Prettier will use .editorconfig if no .prettierrc exists and a .editorconfig file is present.
   2c. Use maintained plugins if needed.
   2d. Remove @stylistic.

3. ESLint for code semantics (e.g. consistent-type-imports, no unused variables, etc.)
   3a. Mostly use defaults.
   3b. Use maintained plugins if needed.
   3c. In CONTRIBUTING.md, recommend adding the ESLint plugin to IDEs.
   3d. Add plugin:prettier/recommended — to disable conflicting ESLint rules and surface Prettier issues as part of ESLint reports (helpful for 3c above so IDEs show Prettier formatting issues).

4. Control / CI (for each repo)
   4a. Add a test:prettier script to package.json that runs prettier --check.
   4b. Add a format:fix script to package.json that runs eslint --fix and prettier.
   4c. Use Husky + lint-staged to run test:prettier, test:lint, test:ejslint as a pre‑commit hook so code with lint or formatting issues can’t be committed.
   4d. Add test:prettier to .github/workflows/test-static.yml in case 4c was bypassed so it would get caught in the PR, etc.

---

Next steps:

• Feedback on the above
• List of repo(s) to fork for setting up items 1 to 3 to assess impact
• Initial implementation in forks ( I can help take a first stab) for assessment and potential pull requests

[christian-bromann]

2. Prettier as the owner for formatting (wrapping, semicolons, quotes, trailing commas, object/array spacing)

Adding tooling adds complexity to devx. Why can't we just use Eslint + stylistic for both (this is an honest question to which I don't know the answer either, hence would love to get some feedback here)? I am also open to explore Biome and comparable tools as it aligns with the idea to consolidate tooling. I personally would prefer OpenJSF projects though.

[YasharF]

Prettier provides deterministic formatting by re-printing the AST, while ESLint+stylistic only checks what it has explicit rules for. Although stylistic offers flexibility for developers to express code intent using formatting outside of rules, it leaves gaps that can lead to inconsistencies. From a devx perspective, the proposed setup makes Prettier issues surface as ESLint errors so contributors only need two script calls: i.e. npm run lint:check (or npm run lint) and npm run lint:fix; the latter runs both eslint --fix and prettier --write, keeping the workflow simple.

Biome is interesting, but Prettier+ESLint is more mature and widely adopted today.

A couple of prior issues about the inconsistencies:

• Unresolved eslint formatting issue: [indent][meta issue] Problems with the indent rule typescript-eslint/typescript-eslint#1824
• The recent JSDoc formatting issue in node-edgedriver and node-geckodriver : chore(dev): bump @wdio/eslint and fix lint issues from new rules webdriverio-community/node-edgedriver#507 (comment) and chore(dev): bump @wdio/eslint and fix lint issues from new rules webdriverio-community/node-geckodriver#648 (comment)