[Feature]: ESLint plugin for Fluent UI React v9 best practices

[NotWoods]

Library

React Components / v9 (@fluentui/react-components)

Describe the feature that you would like added

It would be great to have linter rules to avoid common mistakes with using Fluent UI. I'm creating this feature request to also track ideas for linter rules.

https://github.com/microsoft/fluentui/tree/master/packages/eslint-plugin and https://github.com/microsoft/fluentui/tree/master/tools/eslint-rules exist, but both seem to be designed for internal development rather than act as public packages.

Possible rules

• [ ] Avoid using bundleIcon inside a React component, move it to the module scope (already written)
• [ ] Don't use Fluent UI 8 components that have a corresponding Fluent UI 9 equivalent (already written)
• [ ] Ensure that <Dialog> either wraps <DialogSurface> or a forwardRef component
• [ ] Ensure that <Tooltip> wraps a forwardRef component and supports aria-label, onPointerEnter, etc as props. (unless the tooltip is inaccessible)
• [ ] Prefer using slot objects (such as { className: 'foo', children: <Icon /> }) over divs (such as <div className="foo"><Icon /></div>)
• [ ] Prefer using typographyStyles over fontSize + lineHeight tokens
• [ ] Prefer using tokens over hardcoded fontSize + lineHeight values

Have you discussed this feature with our team

Martin Hochel

Additional context

I've written some linter rules already and would be happy to upstream them.

Validations

• [X] Check that there isn't already an issue that requests the same feature to avoid creating a duplicate.

Priority

Low

[spmonahan]

I'll propose a couple more rules based on my experience:

• [ ] re-export Griffel lint rules (NOTE: this also need to be implemented :))
• [ ] "no circular useMemo". This has come up a couple times. Example. This isn't particularly specific to Fluent though
• [ ] There are many if (process.env.NODE_ENV !== 'production') or similar tests that log development warnings. These are often overlooked because folks either develop with a production build or ignore all the console errors. Shifting these to lint rules makes them more enforceable (i.e., failing lint == failing build) and eliminates code.

[Hotell]

Thanks for this @NotWoods , this is something that would provide huge values to our users !

Regarding priorities we should land this one first "Don't use Fluent UI 8 components that have a corresponding Fluent UI 9 equivalent".

There are some efforts within our internal teams to actually write something like that, so this could prevent us doing any kind of duplication.

For the rest of rules it's up to discussion with core team.

@spmonahan

re-export Griffel lint rules (NOTE: this also need to be implemented :))

That would introduce unnecessary complexity and maintenance overhead on core repo. In order to follow best practices eslint rules/plugins should be consumed separately.

on the other hand we already provide this antipattern by re-exporting parts of @griffel/react via react-components .... well

[spmonahan]

Ah, well we don't necessarily need to re-export them if it's a maintenance issue but we do need to socialize them because I've observed several common Griffel errors that would be caught by lint that are going unnoticed :(

[NotWoods]

A separate "recommended config" package could include both the griffel plugin and this new Fluent UI plugin

[Hotell]

we have core team agreement to proceed with this (shipping a new lint plugin incorporating best practices rules).

TODOs:

• bootstrap new project within monorepo that will host these rules (ETA end of quarter/start of next quarter)
• work with @NotWoods to land first rule -> Don't use Fluent UI 8 components that have a corresponding Fluent UI 9 equivalent (already written)
• shape process behind accepting rules to this package

[dmytrokirpa]

Hey @NotWoods, the package @fluentui/eslint-plugin-react-components has already been bootstrapped. We are now ready to proceed with the first rule: Don't use Fluent UI 8 components that have a corresponding Fluent UI 9 equivalent. Could you please open a PR for this or provide some details on where it is implemented so I can work on it?

[dmytrokirpa]

The package and the first rule have already been merged and published. All subsequent rules will be added one by one though separate issues/requests