[PAY-3166] Updates ESLint dependencies to fix broken IDE experience

[schottra]

Description

(Side note: it's funny to me that a day and a half of effort resulted in such a small changeset...)

The ESLint extension has been randomly not working for some time. This is due to a bug in said extension that causes it to stop working when it encounters a fatal error in parsing configurations.

While investigating, I noticed that some of our workspaces/packages had older versions of ESLint installed in their local node_modules folder. These older versions did not support some of the options in our shared config file and would exit and brick the extension.

These older versions continued to stick around despite updating package.json files for said packages to the correct version. (8.56.0 being the common version across our packages). The cause here was leftover entries in package-lock.json that were not removed during hoisting. The flow is roughly as follows:

1. Root directory has a dependency on eslint@8.56.0 and identity-service depends on eslint@7.x.
2. Version 8.56.0 installed at node_modules/eslint and version 7.x installed at packages/identity-service/node_modules/eslint. T
3. The package-lock.json file will have an entry for each of these.
4. identity-service/package.json is updated to upgrade the dependency to version 8.56.0 either through manual editing of the file or through npm i --save-dev --save-exact -w identity-service eslint@8.56.0.
5. package-lock.json is not updated to remove the entry for packages/identity-service/node_modules/eslint
6. Subsequent installations via npm i at any level of the repository will read the wrong version from package-lock.json and install version 7.x into packages/identity-service/node_modules/eslint
7. Extension starts at the currently opened file and traverses upward to look for a valid eslint binary and finds the v7.x version in packages/identity-service/node_modules
8. Chaos ensues.

The crux of the issue is that the entry for packages/identity-service/node_modules/eslint will not be removed without explicitly uninstalling the module from the identity-service workspace (i.e npm rm -w identity-service eslint) and then re-installing the correct version (npm i --save-dev --save-exact -w identity-service eslint@8.56.0). During installation, when the version matches the version at the root, the package is properly hoisted/deduped and we get a single entry in package-lock.json for node_modules/eslint pointing to the shared version.

So!

With all that preamble out of the way...

• I've followed the above procedure for uninstalling/reinstalling eslint for most workspace packages to normalize us on 8.56.0.
• Additionally, I updated any plugin/config packages for eslint/prettier/standard to match those in eslint-config-audius if they were older. The ddex workspaces actually use newer versions, so I didn't want to downgrade them. The goal here was to update any plugins which referenced old incompatible versions so that npm ls --workspaces --include-workspace-root eslint shows a clean log of eslint versions with no "invalid" entries.
• I did not fix any ESLint errors that popped up in services as a result of getting linting working again. I will fix any that prevent CI from merging cleanly.

The biggest offender for old packages was identity

Some future work we should do:

• Migrate all of our packages to reference/extend the shared Audius eslint config (as a peer dep?) instead of installing their own versions of all of the config/plugin packages and then partially duplicating the setup from the shared config.
• Fix a few "invalid" eslint plugin packages such as eslint-config-jest which are on incompatible versions in a few of the workspaces.
• Update all eslint to use the version the ddex packages are on (9.1.0)
• Write and run a script to help us find and remove any other orphaned hoisted dependencies!

How Has This Been Tested?

1. Wiped and reinstalled node_modules after the change
2. Restarted VSCode
3. Opened a js/ts file in every workspace and examined the ESLint output to make sure it finished linting without any config errors
4. npm run verify to ensure linting still works correctly

[changeset-bot]

⚠️ No Changeset found

Latest commit: 72ec807

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[schottra]

The majority of the important change is here. But since lockfiles are always huge, I doubt you will be able to see it :-(

[rickyrombo]

Thank you!!!! 🚀 🚀 🚀

[sliptype]

Migrate all of our packages to reference/extend the shared Audius eslint config (as a peer dep?) instead of installing their own versions of all of the config/plugin packages and then partially duplicating the setup from the shared config.

It shouldn't need to be a peer dep, we can just install the latest version of eslint-config-audius in every package that needs it and when we bump the version via changesets it will update in all the packages

[sliptype]

Amazing! Thank you for getting to the bottom of this 🙏