feat(eslint-plugin-react-components): add prefer-fluentui-v9 rule

[dmytrokirpa]

Previous Behavior

--

New Behavior

• Added new rule prefer-fluentui-v9 to eslint-plugin-react-components to enforce the use of Fluent UI v9 equivalent for Fluent UI v8 components.
• Added it to the recommended config.
• Updated docs

Example of output:

fluentui/apps/vr-tests/src/stories/Toggle.stories.tsx
  4:1  warning  Avoid importing Toggle from '@fluentui/react', as this package has already migrated to Fluent UI 9. Import Switch from '@fluentui/react-components' instead  @fluentui/react-components/prefer-fluentui-v9

fluentui/apps/vr-tests/src/stories/Tooltip/Tooltip.stories.tsx
  4:1  warning  Avoid importing TooltipHost from '@fluentui/react', as this package has already migrated to Fluent UI 9. Import Tooltip from '@fluentui/react-components' instead  @fluentui/react-components/prefer-fluentui-v9

Related Issue(s)

• Partially implements [Feature]: ESLint plugin for Fluent UI React v9 best practices #32183

[github-actions]

📊 Bundle size report

✅ No changes found

[dmytrokirpa]

cc @NotWoods

[github-actions]

Pull request demo site: URL

[Hotell]

some comments that need to be addressed as part of PR but others can be a follow-up. approving to unblock once the change file is tweaked.

stoked to have 1st rule being shipped soon !
ty

[Hotell]

wondering if this is good idea at this stage - any kind of modifications of config presets will be a breaking change for users. personally I'm fine having it as we properly follow semver.

[dmytrokirpa]

The preset usage is entirely optional. Consumers can always switch to individual rules if they prefer.

[Hotell]

yeah what I meant is scenario once someone adds recommended preset to application - and we introduce BC they will be affected ( with picked rules manually not so much )

[Hotell]

suggestion: it would be probably better to use 1 Schema ( more verbose ) so every value has component and package.

that would remove need of getMigrationDetails completely

[Hotell]

wondering if we could generate this list by automation and update when we trigger stable release for v9 controll

[dmytrokirpa]

We can consider adding components to the map during the transition from preview to stable. However, we still need to define the relationship between the v8 and v9 components.

[Hotell]

yeah some json metadata file per project sounds like good pattern ( which can be than leveraged for any kind of automations like this - I started implementing something like that for triage automation, will share more info later )

[Hotell]

this will not work for lazy imports ( not sure how often that appears in user land with fluent but we should add it as a follow-up)

const lazyComponents = await import('@fluentui/react');

[dmytrokirpa]

Based on the example you gave, it's tough to do a static analysis to figure out which v8 components are used and suggest v9 alternatives. It might be doable, but I'm not sure if it's worth the effort. We could add a warning with a generic message, but I'm not sure how useful that would be.

[Hotell]

implementation/effort wise it's +- same logic with additional parse of destructured symbol but for different AST query selector. There is no additional complexity behind it.

users might use lazy loading modules in any kind of Suspense context or for lazy loaded application routes for perf reasons.

example: calendar is non trivial component having huge bundle size impact, in application context you don't wanna have it part of default bundle.

i think it is worth it to cover this scenario. Regarding internal users of v8 and lazy loading we need more data indeed.