Remove pnpm hoisting for eslint

[anomiex]

Changes proposed in this Pull Request:

This involves moving the bits of eslint configuration that load plugins
or sharable configs into tools/js-tools/eslintrc/, so the plugins and
configs can be loaded relative to that directory instead of relative to
wherever the origin .eslintrc.js file happens to be.

This also drops the dep on @sveltejs/eslint-config, which hasn't been
used since #23482.

And for some reason projects/js-packages/shared-extension-utils/ had
both .eslintrc.js and .eslintrc.cjs, with identical content. So I
deleted one.

Jetpack product discussion

None

Does this pull request change what data or activity we track or use?

No

Testing instructions:

• Do pnpm install, then check that node_modules/.pnpm/node_modules/ no longer exists.
• pnpm lint should complete and give the same list of warnings and errors that it does in master.
• For any directory with an eslintrc file, pnpm lint-file path/to/dir should complete and give the same list of warnings and errors that it does in master. Except for projects/plugins/jetpack/modules/widget-visibility/editor, which is currently broken in master and is fixed here.
• Someone with vscode should check that vscode's eslinting still works too.

[github-actions]

Thank you for your PR!

When contributing to Jetpack, we have a few suggestions that can help us test and review your patch:

• ✅ Include a description of your PR changes.
  
• ✅ All commits were linted before commit.
  
• ✅ Add a "[Status]" label (In Progress, Needs Team Review, ...).
  
• ✅ Add testing instructions.
  
• ✅ Specify whether this PR includes any changes to data or privacy.
  
• ✅ Add changelog entries to affected projects
  

This comment will be updated as you work on your PR and make changes. If you think that some of those checks are not needed for your PR, please explain why you think so. Thanks for cooperation 🤖

---

The e2e test report can be found here. Please note that it can take a few minutes after the e2e tests checks are complete for the report to be available.

---

Once your PR is ready for review, check one last time that all required checks (other than "Required review") appearing at the bottom of this PR are passing or skipped.
Then, add the "[Status] Needs Team review" label and ask someone from your team review the code.
Once you’ve done so, switch to the "[Status] Needs Review" label; someone from Jetpack Crew will then review this PR and merge it to be included in the next Jetpack release.

---

Jetpack plugin:

• Next scheduled release: June 7, 2022.
• Scheduled code freeze: May 31, 2022.

---

Boost plugin:

• Next scheduled release: June 7, 2022.
• Scheduled code freeze: May 30, 2022.

[matticbot]

Caution: This PR has changes that must be merged to WordPress.com
Hello anomiex! These changes need to be synced to WordPress.com - If you 're an a11n, please commandeer and confirm D80730-code works as expected before merging this PR. Once this PR is merged, please commit the changes to WP.com. Thank you!
This revision will be updated with each commit to this PR

[sdixon194]

This works for me! There are some merge conflicts that need fixing. Not sure if we can just checkout master here since you touch some lock/package.json files 🤔

[anomiex]

Needs reapproval after master merge

[anomiex]

r245830-wpcom

[github-actions]

Great news! One last step: head over to your WordPress.com diff, D80730-code, and deploy it.
Once you've done so, come back to this PR and add a comment with your changeset ID.

Thank you!

[manzoorwanijk]

@anomiex I think we should extend require.resolve( 'jetpack-js-tools/eslintrc/typescript' ) in these two files as well:

• projects/plugins/jetpack/.eslintrc.js
• projects/js-packages/components/.eslintrc.cjs

Or may be extend it in base config itself to make it available globally because it will be used only for TS files.

[anomiex]

Except it apparently isn't just used for typescript files, since tools/js-tools/eslintrc/typescript.js disables no-duplicate-imports and no-undef, and also has an overrides to disable @typescript-eslint/no-var-requires for root .cjs files.

[manzoorwanijk]

We can override those rules or use overrides to apply the rules only to .ts and .tsx files.

Simply put, we need that TS related ESLint config wherever we use TS, otherwise we will end up having many unwanted lints like this

[anomiex]

If we can merge it into the base with overrides so the TS stuff doesn't interfere with the non-TS stuff, I'd be happy to go with that.

[manzoorwanijk]

Add this simple override in js-tools/eslintrc/base.js should do the job:

overrides: [
	{
		files: [ '*.ts', '*.tsx' ],
		extends: './typescript',
	},
],

After adding that, we don't need to extend typescript config here in plugins/boost/.eslintrc.cjs
We may also be able to remove @typescript-eslint/no-var-requires override for root .cjs files.

[manzoorwanijk]

If I do this in js-tools/eslintrc/typescript.js

diff --git a/tools/js-tools/eslintrc/typescript.js b/tools/js-tools/eslintrc/typescript.js
index 4df6d88f9a..5b9ca0738c 100644
--- a/tools/js-tools/eslintrc/typescript.js
+++ b/tools/js-tools/eslintrc/typescript.js
@@ -12,12 +12,15 @@ module.exports = {
                'no-undef': 0,
 
                '@typescript-eslint/no-unused-vars': [ 'warn', { argsIgnorePattern: '^_' } ],
+               '@typescript-eslint/ban-ts-comment': 0,
        },
        overrides: [
                {
-                       files: [ '*.cjs' ],
+                       files: [ '*.js', '*.cjs', '*.jsx' ],
                        rules: {
                                '@typescript-eslint/no-var-requires': 0,
+                               '@typescript-eslint/no-empty-function': 0,
+                               '@typescript-eslint/no-this-alias': 0,
                        },
                },
        ],

And then directly extend ./typescript in base.js, then there are no lints left.

Is that something we can do?

[anomiex]

I think I like your suggestion in #24355 (comment) better than the one in #24355 (comment)

The first suggestion limits typescript checking to just the typescript files, which seems good. It would also let us remove the override in projects/plugins/boost/.eslintrc.cjs since those would no longer be being checked as typescript either.

When I try it locally, it reports four new errors:

/usr/local/src/automattic/jetpack/projects/js-packages/components/components/text/types.ts
  45:44  warning  Unexpected any. Specify a different type  @typescript-eslint/no-explicit-any
  46:20  warning  Unexpected any. Specify a different type  @typescript-eslint/no-explicit-any

/usr/local/src/automattic/jetpack/projects/plugins/boost/app/assets/src/js/elements/Toggle.svelte
  2:14  error  Parsing error: Missing semicolon. (3:13)

/usr/local/src/automattic/jetpack/projects/plugins/boost/app/assets/src/js/pages/settings/elements/RatingCard.svelte
  28:11  error  'Jetpack_Boost' is not defined  no-undef

The first two seem to be because js-packages/components isn't doing the typescript lints yet. The third seems to be because the svelte file has embedded typescript but the typescript parser isn't being used. The last is because a rule supposedly disabled just for typescript was accidentally applying to the svelte files too.

That last is why I don't care for your second comment's suggestion, as it would apply those to all files rather than only to typescript files.

P.S. In either case, we could probably just merge the config into base.js instead of having a separate typescript.js.

[manzoorwanijk]

Alright, thank you for your thoughts. Here is #24579 to fix the issue.