This commit fixes that oversight in package.json and rectifies all the fall-out from this mistake.
First, I finished the migration to the new eslint.config.js format. To avoid further bugs, I first enabled TypeScript's type checking via @ts-check. I then followed the migration guide from https://eslint.org/docs/latest/use/configure/migration-guide to fix the config in general.
Doing so, I changed a the linter config in the following way:
I disabled the max-classes-per-file linter rule. My change #365 violated this rule. But I don't think that this rule provides much value in general. Having one class per file is rather a Java convention than a JavaScript convention...
I replaced prefer-arrow/prefer-arrow-functions by the built-in prefer-arrow-callback. Afaict, those checks do the same. This allowed me to remove the dependency on the package eslint-plugin-prefer-arrow.
The linting actually alos applied to the eslint.config.js file itself. But not all packages have types, zet. I hence disabled a couple of rules for this file.
With that out-of-the way, I had to fix the actual lint warnings:
In `eslint-plugin-prefer-arrow bazel_workspace_info.ts and buildifier.ts: "Unexpected lexical declaration in case block"
extension.ts had an (intentionally) dangling promise
debug-adapter/connection.ts had an intentional while(true) loop.
In #363, I accidentally disabled all eslint checks: I used
eslintand thought this would actually run the linter on the complete source tree. Starting from ESLint 9.0, this will actually work (See https://eslint.org/blog/2024/04/eslint-v9.0.0-released/#running-eslint-with-no-file-arguments). But for ESLint 8.x, we still need to useeslint .This commit fixes that oversight in
package.jsonand rectifies all the fall-out from this mistake.First, I finished the migration to the new eslint.config.js format. To avoid further bugs, I first enabled TypeScript's type checking via
@ts-check. I then followed the migration guide from https://eslint.org/docs/latest/use/configure/migration-guide to fix the config in general.Doing so, I changed a the linter config in the following way:
max-classes-per-filelinter rule. My change #365 violated this rule. But I don't think that this rule provides much value in general. Having one class per file is rather a Java convention than a JavaScript convention...prefer-arrow/prefer-arrow-functionsby the built-inprefer-arrow-callback. Afaict, those checks do the same. This allowed me to remove the dependency on the packageeslint-plugin-prefer-arrow.eslint.config.jsfile itself. But not all packages have types, zet. I hence disabled a couple of rules for this file.With that out-of-the way, I had to fix the actual lint warnings:
while(true)loop.