Upgrade production dependencies with Angular 14 support.

[TrevorKarjanis]

• Upgrade eslint, @typescript-eslint, @angular-eslint, and eslint-config-airbnb-base major versions.
• Add a diff script to compare old and new rule sets.
• Fix a bug caused by incorrect devDependencies in @ni/eslint-config-typescript.
• Fix the character casing of npm and ESLint.

This PR tries not to break downstream consumers by introducing changes to the rule set.

• The diffs of the rule set after upgrading and after addressing breaking changes are attached.
  • upgrade-rules-diff.txt
  • fix-rules-diff.txt
• import/no-extraneous-dependencies has a complex configuration and only added "**/.eslintrc.js" to its devDependencies option which I don't think is a breaking change.
• no-confusing-arrow added the onlyOneSimpleParam option, but uses the default value.
• @angular-eslint/template/i18n has a complex configuration and enabled the checkDuplicateId option, but NI doesn't specify IDs.
• Changes to the implementation of already enabled rules can cause errors.

Notes

• This is required to support the latest ECMA features like private fields.
• This is required to support Angular 14.
• Drop support for Angular 11 and below.
• The @angular-eslint/schematics dependency ensures ESLint is configured for newly generated projects.
• As per their branding, npm should never be uppercase.

Linted and tested

• Manually verified that upgrading the package in a consumer works correctly
• Verified that automated testing passes

[jattasNI]

@TrevorKarjanis is there anything blocking us from taking this PR out of Draft state and getting it reviewed/submitted?

[TrevorKarjanis]

@TrevorKarjanis is there anything blocking us from taking this PR out of Draft state and getting it reviewed/submitted?

The biggest pain here was identifying new rules. I did so manually at first. My next step is to use the utility Milan created to print a before and after, and compare them to verify the findings described here. We then need to decide on our policy. My thought is to disable them if they are recommended, and create an issue to evaluate all of them appropriately so that upgrade PRs aren't blocked by a potentially lengthy process. As we saw in our initial evaluation, blindly enabling them is not practical. We could also take a quick pass to identify obvious cases that align or violate existing conventions.

After that, the dependencies in the PR just need to be upgraded again. Run the tests, update the README, and post the PR.

[jattasNI]

Let me know if I can help in any way. This iteration our team is driving the Angular 13 upgrade in many of the apps and libs that depend on this, so getting this in will be an important step and something we'd be happy to help with.

[rbell517]

Is there an update on this PR? I'm trying to apply these rules to Skyline's EndToEndTests subdir and its using ES2022 features. I can change the handful of places we use those features but if this is close then I might as well wait.

[TrevorKarjanis]

Is there an update on this PR? I'm trying to apply these rules to Skyline's EndToEndTests subdir and its using ES2022 features. I can change the handful of places we use those features but if this is close then I might as well wait.

You're adding linting to the end-to-end tests? You're a hero! This effort will hopefully restart next week, as myself and many involved are heavily involved in the latest customer effort. This is also a part of our larger migration to Angular 13. I would suggest regressing those features temporarily as that is likely much easier than this.

[rajsite]

@TrevorKarjanis FYI you will need to create a new PR based on a branch from the ni repo instead of branch from your fork to merge

[TrevorKarjanis]

@TrevorKarjanis FYI you will need to create a new PR based on a branch from the ni repo instead of branch from your fork to merge

I happen to be doing exactly that! Thanks.