Migrate to @liferay/eslint-plugin

[wincent]

This is something that I have been putting off for a while, because renaming packages is a pain, but I think we'll eventually have to do it: move eslint-config-liferay to eslint-plugin-liferay.

As I explained in 5850f26d0f9e4c03872a2:

ESLint surprisingly doesn't make it easy for you to bundle rules with a config, requiring you to publish a separate package. That is, if you have "eslint-config-foo", you have to stick your rules in "eslint-plugin-foo". The inverse doesn't appear to be true: if you have "eslint-plugin-foo", you can bundle configs with it without having to create "eslint-config-foo".

We however, have "eslint-config-liferay", and I don't want to create yet another package, so we use a horrifying but well-contained hack that is hidden away in utils/local.js to enable us to bundle local rules with our config.

The trouble with this hack is that:

• It is hideously ugly, requiring us to monkey-patch ESLint at runtime.
• It is sensitive to upstream changes in ESLint (eg. we have to maintain two or three versions of the hack, one for v5 and two for v6+; see 7c67c4c89d7a37bef8 and https://github.com/liferay/liferay-frontend-projects/pull/430).
• Because we have to monkey-patch ESLint, it is sensitive to multiple versions of ESLint being present in the environment, lest it patch the wrong one (see 944deeb32b0b0b and de4388a6b9a672 for examples of how we have to guard carefully against that).

Overall, things are working for now, but this feels like a liability. It would be much better to be able to freely update ESLint without worrying about whether the hack still works, or having to deal with edge cases stemming from people using the config in different ways.

Tentative plan of action:

• [x] Create an eslint-plugin-liferay placeholder package on NPM to reserve the name — we should do this immediately, then do the following steps whenever we consider optimal.
• [x] Restructure eslint-config-liferay to be a plug-in, publish it as eslint-plugin-liferay; as part of this, remove the monkey-patching hack.
• [x] #677
• [x] Rename GitHub repo (I believe GitHub will set up a redirect for this, which means that old links won't be broken) — will require us to open up an LRIT ticket.
• [x] Mark the eslint-config-liferay package as deprecated with npm deprecate, directing people to use eslint-plugin-liferay instead.

I wish we'd known back in 2017 that a plugin would be better than a config, but we didn't and so them's the breaks. For reference, there are currently 1,187 NPM packages with the keyword "eslint-plugin" vs 809 with keyword "eslint-config". Examples of popular packages which are plugins bundling both rules and config include:

• eslint-plugin-react
• eslint-plugin-react-hooks
• eslint-plugin-prettier

(All of which, we already use).

[wincent]

Seeing as I just linked to here from https://github.com/liferay/generator-liferay-fragments/commit/1300901a37da8f4175ebd143ed5f277bd65ef427 — it should be noted that this ticket was created before migrating the contents of the eslint-config-liferay repo into this monorepo, and before we started using the named @liferay/ scope on npm.

Bear that in mind when reading the description above; we still want to do this, but it won't be via eslint-plugin-liferay, but rather @liferay/eslint-plugin. Other than that, the above all still applies.

[bryceosterhaus]

Closing and spawned off new ticket to update existing projects, https://github.com/liferay/liferay-frontend-projects/issues/677