Upgrade to Node.js v20 & define additional linting rules

⚠️ BREAKING CHANGES ⚠️

• Minimal supported Node.js 18 version is raised to >=18.18.2 (#31)
• Packages @typescript-eslint/eslint-plugin and @typescript-eslint/parser got major version upgrade to v6.9.1 (#31)
• Package eslint-config-prettier got major version upgrade to v9.0.0 (#31)
• ESLint base config is now distributed via JS file and JSON format is no longer supported. This is done to prepare for flat ESLint config which will be rolled out in v9 (#31)

Other changes

• Minimal supported Node.js 20 version is >=20.9.0 (#31)
• Minimal supported NPM 10 version is >=10.2.2 (#31)
• Typescript peer dependency updated to v5.2.2 (#31)
• ESLint peer dependency updated to v8.52.0 (#31)
• Prettier base config uses trailingComma: 'es5' to keep the same behavior between v2 and v3 of Prettier (#31)

Linting rule changes

• Start using unicorn ESLint plugin for lots of new linting rules. Some rules are disabled though:
  • consistent-function-scoping: There are use cases where we want inline functions
  • expiring-todo-comments: There is no particular need to expire TODO comments. There is a bunch of years-old TODO comments in some HPC repositories
  • explicit-length-check: Just checking by if (!array.lenght) {}, instead of if (array.lenght === 0) {} is enough and readable already
  • filename-case: Although using a single casing for file names is a great idea, it would be hard to resolve all the problems that would be reported by this rule in HPC repos. For newer code, there was an agreement to use kebab-case (like in hpc-api). But if we accept that everywhere, model files in hpc-api-core would break camelCase standard used in DB table names. If we were to enforce camel case, there could be a conflicting use case to have a util file named io-ts.ts, so I decided not to have any file naming standard for now
  • no-array-reduce: The reasoning of unicorn developers is that Array.prototype.reduce() is producing a hard-to-read code, but that is highly opinionated and we didn't want to disable the usage. Biggest problem is when reduce is used to traverse an array and it should only be used when a scalar result is produced
  • no-array-callback-reference: This rule would prevent heavy usage of .filter(isDefined) that HPC has across various repos
  • no-await-expression-member: Conflicts with Prettier's formatting style
  • no-negated-condition: Although it could be argued that negated conditions are harder to read, this rule would be too restrictive
  • no-null: We definitely want to keep using both null and undefined in HPC codebases
  • prefer-code-point: HPC codebases don't need that much Unicode support for this to make a difference
  • prefer-number-properties: There is a mix and match of isNaN and Number.isNaN usages across HPC repos, which would be hard to standardize
  • prefer-string-slice: Substring is such a common term in programming terminology that we don't want to get rid of it
  • prefer-switch: switch statements aren't much easier to read and we don't want them replacing some if..else structures
  • prefer-ternary: Some people would advocate usage of ternary is a code smell and we don't want to enforce their usage
  • prefer-top-level-await: This would require HPC to switch to ES modules, which we want eventually, but aren't ready yet
  • prevent-abbreviations: Some notable people in the industry think that Hungarian notation has its place and this rule would prevent such usages. We don't want to have to rename args to arguments_ because it would conflict with a reserved keyword
  • switch-case-braces: This is stylistic taste, but curly braces in switch..case block look so weird
  • text-encoding-identifier-case: We cannot enforce usage of 'utf8' because in some cases it needs to be 'utf-8'
• Started using prettier-plugin-organize-imports to make sure formatting checks also make sure import order is right. This plugin was chosen because it uses same tooling behind VS Code's "Organize imports", thus making usage much simpler compared to another linting plugin. So, when there is a problem with import order, developers will just format the file (or use "Organize imports" in VS Code) and not have to invoke linting auto-fixing
• Added more strict linting rules, both from plain ESLint and from @typescript-eslint plugin:
  • no-else-return: Disallow else blocks after return statements in if statements
  • no-multi-assign: Disallow use of chained assignment expressions
  • no-unneeded-ternary: Disallow ternary operators when simpler alternatives exist
  • no-useless-concat: Disallow unnecessary concatenation of literals or template literals
  • prefer-template: Require template literals instead of string concatenation
  • For Typescript files, additional rules:
    • no-array-constructor: Disallow generic Array constructors
    • array-type: Require consistently using either T[] or Array<T> for arrays
    • await-thenable: Disallow awaiting a value that is not a Thenable
    • consistent-generic-constructors: Enforce specifying generic type arguments on type annotation or constructor name of a constructor call
    • consistent-type-imports: Enforce consistent usage of type imports
    • prefer-nullish-coalescing: Enforce using the nullish coalescing operator instead of logical assignments or chaining
    • prefer-optional-chain: Enforce using concise optional chain expressions instead of chained logical ands, negated logical ors, or empty objects