Update to Angular 18

[m-akinc]

Addresses #157

In addition to updating the dependency version, I'm fixing the following:

• Upgrade @typescript-eslint/eslint-plugin @typescript-eslint/parser #150
• Uptake new angular-eslint runtime-localize rule #153

Implementation

Updated dependencies:

• @angular/core to 18.2.13 (latest <19)
• @angular-eslint packages to 18.4.3 (latest <19)
• @typescript-eslint/eslint-plugin and @typescript-eslint/parser to 7.18.0 (latest <8)

After updating the version of @typescript-eslint/parser, I began getting the following test failure:

Error: Error while loading rule '@typescript-eslint/prefer-optional-chain': You have used a rule which requires parserServices to be generated. You must therefore provide a value for the "parserOptions.project" property for @typescript-eslint/parser.
Parser: C:\dev\javascript-styleguide\node_modules\@typescript-eslint\parser\dist\index.js
Occurred while linting C:\dev\javascript-styleguide\tests\typescript\index.ts

One of the typescript-eslint maintainers says that the rule does not require parserServices and seems to credit the error to using the rule on a non-ts file or with parser other than @typescript-eslint/parser, but that doesn't seem to be the case for our tests. In any case, clients should already be setting parserOptions.project for running eslint on their ts files, so I wouldn't expect this to cause issues.

Testing

• Ran npm run print-evaluated-rules:diff and the only change is that the no-host-metadata-property rule was removed from the recommended eslint-plugin config (rule is deprecated in version 18 and fully removed in version 19). This should not break clients, as the rule still exists (so clients can still turn it on/off) and the default config is just more permissive.
• Ran npm run print-evaluated-rules to do an audit, which turned up
  no warnings or diverged rules.
• Ran npm run print-available-rules and the only new rule available in the updated version was @angular-eslint/runtime-localize, which we now enable.

[m-akinc]

Won't submit until ready to update clients.

[jattasNI]

Ran npm run print-evaluated-rules:diff and the only change is that the no-host-metadata-property rule was removed from the recommended eslint-plugin config (rule is deprecated in version 18 and fully removed in version 19). This should not break clients, as the rule still exists (so clients can still turn it on/off) and the default config is just more permissive.

I'd like to figure out the long term plan for adapting to this deprecation and if there's any work to do, decide whether to do it now.

Here is the PR that removed that rule: angular-eslint/angular-eslint#2113

It looks like Angular changed their recommendation to prefer this syntax

@Component({
  selector: '[mat-menu-item]',
  host: {
    '[class.mat-menu-item-highlighted]': '_highlighted',
  }
})

over the @HostListener and @HostBinding directives:

@HostBinding('class.my-menu-item-highlighted')
  _highlighted: boolean = false;

This reddit post has some good examples of before / after.

They have an unimplemented feature request to write the rule to enforce that new preference: angular-eslint/angular-eslint#2189

I searched our codebase and didn't see anything setting no-host-metadata-property (except for one non-maintained codebase) but I did see several instances of @HostListener and @HostBinding. So I think we could either:

1. keep this PR as-is and nothing will break, but we'll be violating Angular's new recommendation for @HostListener/@HostBinding.
2. do some work to migrate / delete those usages. That work could happen now or during the 19 upgrade or whenever that new rule is introduced

Any votes between 1 and 2?

[m-akinc]

I vote 1. I'm not sure the rationale for the reversed convention is compelling enough to warrant taking any action now. If there were a rule to enforce the new, reversed recommendation, I'd be more convinced that we should turn it on and fix violations.

[m-akinc]

The new version of eslint-plugin's package.json file no longer has "main": "dist/index.js" and instead uses the newer "exports" property. Unfortunately, eslint-plugin-import doesn't know how to resolve entry points in commonjs modules that are declared using "export". See typescript-eslint/typescript-eslint#7565 and import-js/eslint-plugin-import#2703