Feature: publish eslint rules to help promote better Fbt API usage practices

[kayhadrin]

🚀 Feature Proposal: publish fbt eslint rules

Following #327 (from @alexandernanberg), we should expose a bunch of our internal eslint rules to help developers use the Fbt API properly.

Motivation

Across a large UI app, it's important to ensure that all strings are localized.
Having some eslint rules to help spot easy issues would help drive adoption, quality & consistency in a project's codebase.

Here are some of the eslint rules we have implemented internally:

• enforce-fbt-project.js
  Force users to specify an fbt project name at the callsite or file header level
• fbt-common-strings.js
  Recommend users to use fbt.c() / <fbt common={true}> whenever they are redefining an existing common word. E.g. Facebook
• fbt-empty-string.js
  Prevent users from writing empty strings. E.g. fbt(''), <fbt></fbt>
• fbt-no-unwrapped-strings.js
  Prevent users from assigning plain strings to HTML element children/attributes (in a React app context).
  NOTE: this is similar to what you just implemented.
• fbt-unhelpful-desc.js
  Prevent writing descriptions that are a duplicate of the text, or just too short.
• fbt-unregistered-project.js
  Prevent defining fbt project names are have not been created in our backend yet.
• no-capital-fbt.js
  Recommends using <fbt> instead of <Fbt>

They've not yet been exported to the OSS community yet, but we'd welcome a motivated contributor to port them to the OSS community.

The fbt eslint rules could be defined in this repo as more yarn workspaces, and published as new npm packages.

[alexandernanberg]

I'd be happy to give away the eslint-plugin-fbt name on npm when/if this happens!