eslint-plugin-fbt

[alexandernanberg]

Hey, I've created eslint-plugin-fbt. It only has 1 rule for now (to catch strings that aren't wrapped in <fbt>), but it has already been quite useful in my projects so I thought I could share it here.

I plan on adding more useful rules in the future, so let me know if you have any suggestions!

[mrtnzlml]

Hi @alexandernanberg! 👋 Thank you very much for your initiative, great job! 👍

I am giving it a spin in our monorepo (adeira/universe#3784) and I will let you know if I encounter some issues. 😎

[alexandernanberg]

Awesome, let me know how it goes. I just added a ignoredWords option, that I think would be useful to you by looking at the PR

[mrtnzlml]

Thanks! I was thinking about something similar. 👍 I have there some situations where I am not sure how should they be solved (probably Eslint ignore is the right solution) but this option is great for a product name and similar things which should not be translated.

[kayhadrin]

Nice work @alexandernanberg!

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 been exported to the OSS community yet but if you're interested to help porting them, we could share their "raw" implementation.

On another note, I had a quick look at your implementation and I should let you know that there are two ways to main "fbt API entry points".

1. fbt, written as or fbt()
   It may contain JSX elements to support rich contents.
2. fbs, written as or fbs()
   It can only contain plain text. Useful when you want to ensure your translated string doesn't contain any JSX (used for pure-string HTML attributes like title, placeholder, and other accessibility HTML attributes).

These are defined in FbtConstants.js and having a look at various callsites in our code may help you see how it's being used.

[mrtnzlml]

@kayhadrin I think it would be awesome if you could share the lints you are using internally! 👍

BTW, is fbs available for OSS? I've seen it many times but never understood how to use it or what is it for. It also doesn't seem to be exported from fbt package. 🤔

[kayhadrin]

Created #329 to track this.

BTW, is fbs available for OSS? I've seen it many times but never understood how to use it or what is it for. It also doesn't seem to be exported from fbt package. 🤔

It's already included in the fbt package, but you'll need to import it manually.

import fbs from 'fbt/lib/fbs';

[alexandernanberg]

Oh nice, didn't know of fbs! I've been doing fbt().toString() for attributes but fbs seems much better. Any plans on exporting it from the main entry?

[alexandernanberg]

They've not been exported to the OSS community yet but if you're interested to help porting them, we could share their "raw" implementation.

Yes, I'm interested! However I can't promise I'll have time to implement everything myself.

On another note, I had a quick look at your implementation and I should let you know that there are two ways to main "fbt API entry points".

This just means the plugin should check for fbs elements as well right?

---

Could you elaborate a bit more on the enforce-fbt-project and unregistered-project rules? Sounds like they are FB specific but maybe I'm misunderstanding