microsoft / fluentui

Fluent UI web represents a collection of utilities, React components, and web components for building web applications.
https://react.fluentui.dev
Other
17.87k stars 2.66k forks source link

[Feature]: Add conformance test to ensure context exports are added to the package #31329

Open sopranopillow opened 3 weeks ago

sopranopillow commented 3 weeks ago

Library

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

Describe the feature that you would like added

After talking with some partners it is apparent that when the partner is recomposing components and the component's API later adds a context (adding usecontextvalues) to the component definition, it blocks recomposition (more important bumping versions of fluent) by not exporting these values. We are humans so this mistake can happen, but this proves to be a bad DX for partners.

Have you discussed this feature with our team

No

Additional context

Related: #31328

Validations

Priority

High

Hotell commented 3 weeks ago

This is rather tricky IMO, it should be generalized to "package exports public api surface" rather than "context only - which is not present in every pacakge", but in order to determine that we need to ask a question, what is public API surface and how can we determine that ?

approach that I can think of right awau is to have a 2 parts rule:

Sidenote: this should not be part of conformance test as the overall solution should not be expanded rather ported to custom workspace eslint rules that provides significantly better DX and is much more performant, obviously some patterns can be challenging/impossible to implemented on Eslint side ( probably my 1st rule which would need to parse all sources, gather symbols containing @public JSDOC and compare with export tokens within index.ts ) .

WDYT ?

sopranopillow commented 3 weeks ago

Yeah I think the 1st options sounds the best path. iirc we were going to do this before, but can't remember why we ended up not using those tags. While it does seem like a drag to add this, it would greatly improve DX for partners that use our components by recomposing. Also like you pointed out, the 2nd option may bring issues along the road so I think we should stay away from that kind of path.

Thanks for the side note :) I always immediately think conformance tests, but maybe I should say conformance rules(?) Just want o make sure all components follow this set of rules.