• Update change files for consistency
• Fix some pr comments
• fix merge
• Change files
• Add change files
• update api
• fix api-extractor warnings

Pull request checklist

• [ ] Addresses an existing issue: fixes #16101
• [ ] Include a change request file using $ yarn change

Description of changes

(give an overview)

Focus areas to test

(optional)

…lution kind of TS config

Pull request checklist

• ~[ ] Addresses an existing issue: Fixes #0000~
• [x] Include a change request file using $ yarn change

Description of changes

Before:

• with current setup linting was not working in editors within /tools project
• while debugging I found out our dynamic config provided invalid paths for file property (double slash etc)

After:

• linting now works consistently within /tools project from CLI and Editor
• files are properly normalized

Focus areas to test

(optional)

Pull request checklist

• ~[ ] Addresses an existing issue:~
• [x] Include a change request file using $ yarn change

Description of changes

(give an overview)

Focus areas to test

(optional)

Pull request checklist

• [x] Include a change request file using $ yarn change

Description of changes

Enable the react-hooks/exhaustive-deps lint rule for useIsomorphicLayoutEffect. Also disable the rule in the one place that it caused a failure.

Pull request checklist

• [x] Addresses an existing issue: Fixes #17891
• [x] Include a change request file using $ yarn change

Description of changes

This PR replaces React.useLayoutEffect with useIsomorphicLayoutEffect as it produces warnings during SSR. Also modifies ESLint preset to prevent future usages. Warnings in existing places of v8 code have been suppressed.

See more details: https://medium.com/@alexandereardon/uselayouteffect-and-ssr-192986cdcf7a

Pull request checklist

• [x] Addresses an existing issue: part of #18025
• [x] Include a change request file using $ yarn change

Description of changes

Update eslint-related dependencies to be compatible with TS 4.1, including proper parsing for import type/export type.

After this change, it will probably be necessary for everyone to delete their local eslint caches (yarn rimraf '{apps,packages}/*/.eslintcache' or similar) to avoid some weird false positives.

Thanks to one or more of the updated deps (hard to say which), usage of React components is now flagged! :tada: However, this meant that a bunch more rule disables had to be added, mainly for usage of Fabric and Customizer. Where it made sense and was clearly safe, I went ahead and changed these to use ThemeProvider, but in other cases I just disabled the rule.

There are also a few other interesting changes that I'll comment on inline.

Related references:

• @typescript-eslint/* v4 release notes
• @typescript-eslint/* v3 release notes

• Package version(s): @fluentui/[email protected]
• Browser and OS versions: NA

Actual behavior:

Warning: useLayoutEffect does nothing on the server, because its effect cannot be encoded into the server renderer's output format. This will lead to a mismatch between the initial, non-hydrated UI and the intended UI. To avoid this, u
seLayoutEffect should only be used in components that render exclusively on the client. See https://reactjs.org/link/uselayouteffect-ssr for common fixes.
    at TooltipProvider (@fluentui\react-tooltip\lib-commonjs\components\TooltipProvider\TooltipProvider.js:12:38)
    at div
    at ThemeProvider (@fluentui\react-theme-provider\lib-commonjs\components\ThemeProvider\ThemeProvider.js:8:36)

Priorities and help requested:

Are you willing to submit a PR to fix? Yes Requested priority: Normal Products/sites affected: (if applicable)

Pull request checklist

• [x] Addresses an existing issue: Part of #14691
• [x] Include a change request file using $ yarn change

Description of changes

Best viewed with "ignore whitespace changes" (for a couple of the files)

Previously, several pieces of setup code for the public website (developer.microsoft.com/fluentui) and its local/PR deployed versions had to be duplicated across every major version branch of Fluent/Fabric. This was not ideal since the process of making updates (such as adding a new major version) was very manual and error-prone.

This PR adds and uses a new package @fluentui/public-docsite-setup (open to naming suggestions) to de-duplicate website setup tasks, including:

• Loading the real site (developer.microsoft.com/fluentui): get the "manifest" file for the requested (or latest) major version, then load the current website build for that major version
• Loading the local or PR deploy site
• Setting up the version switcher definition (also provides related types)

Build setup

The build steps/configuration related to this change are as follows. (These build steps will also be added in the 5.0, 6.0, and 7.0 branches, using the @fluentui/public-docsite-setup package from master.)

Some of this is also explained in the public-docsite-setup readme.

| File/pipeline | What's called/done | Details | |--|--|--| | apps/public-docsite webpack configs | getLoadSiteConfig() from under @fluentui/public-docsite-setup/scripts/ | Adds a webpack config that generates dist/loadSite.js (for actual loading) and copies shared index.html to website's dist folder | | Release pipeline azure-pipelines.release.yml | yarn create-site-manifests [main package path] [CDN URL root] (script is from @fluentui/public-docsite-setup's bin) | Generates "manifest" files (under site-manifests/v8-prod.js and v8-df.js) with:
- the URL where files from that build will be uploaded
- the full version of @fluentui/react | | Release pipeline azure-pipelines.release.yml | "Publish artifact: fabric-website-manifests" task | Uploads the generated manifest files as a build artifact | | Website release pipeline (internal) | Upload manifest files to live location | |

Additional manual step (as needed): since the live site actually uses bootstrap code stored in an internal repo, manually copy apps/public-docsite/homepage.htm and apps/public-docsite/dist/loadSite.js to the internal repo

What happens at runtime

At runtime, we start with the HTML file loading the loadSite.js bundle. (The bundle is generated by webpack from @fluentui/public-docsite-setup/src/loadSite.ts, using the getLoadSiteConfig() helper.)

The version switcher definition is read from the global by apps/public-docsite/src/SiteDefinition/SiteDefinition.tsx, and various places in the site consume it from there.

Open questions

As the PR is now, there's quite a mix of "fabric" or not in naming. Open for suggestions for what to do here. (Also okay with just going with it as-is.)

| Thing | Name | Notes | |--|--|--| | Main website webpack bundle | fabric-site | A slight improvement over previous name fabric-sitev5. Could let this vary across branches, but it's easiest if we don't. | | Website-related artifacts in azure-pipelines.release.yml | fabric-website-whatever | Again easiest if these stay the same across branches. Inclined to leave as-is to reduce work updating the website release pipeline (and slightly reduce churn in old branches). | | Shared setup package | public-docsite-setup | Follows website naming convention from master. Will be used in other branches but that's probably fine. | | Shared bootstrap file | loadSite.ts/.js | | | Types from shared package | SiteConfig, SiteGlobals | | | Manifest creation script | create-site-manifests | | | Generated manifest files | site-manifests/vN-prod.js | | | Global defined by manifest files | __siteConfig | |

Pull request checklist

• [x] Addresses an existing issue: Part of #14692
• [x] Include a change request file using $ yarn change

Description of changes

Change all version 8-related packages to non-beta versions as the final step of the major release.

Change the repo default beachball config back to:

  disallowedChangeTypes: ['major', 'prerelease'],
  tag: 'latest',

As a result of this change, most pre-release package beachball configs must be updated to maintain current versions. (Some of the current versions violate the 9.0.0-alpha convention we discussed last week, but that can be fixed separately.)

Open questions

• react-shared-contexts: currently at 1-beta and used by both v8 (ContextualMenu) and react-button--what to do? (PR currently adds special beachball config to keep as-is)

Deleted package

Due to changes in plans I don't think we need this. We can bring it back later if needed.

• ie11-polyfills

v8-related packages bumped to major < 8

These packages were previously on N-beta where N > 0 and < 8. To go with prior convention I just removed the -beta suffix and kept the major version.

• common-styles: 1
• dom-utilities: 2
• eslint-plugin: 1
• monaco-editor: 1
• react-charting: 5
• react-icons-mdl2: 1
• react-icons-mdl2-branded: 1
• react-icon-provider: 1 (was previously 0.x, agreed to bump to 1)
• react-monaco-editor: 1
• react-window-provider: 2
• theme: 2

Bumped to version 8

• api-docs
• azure-themes
• codemods (changed from 1 b/c seems like this should match suite version)
• date-time-utilities
• example-data
• font-icons-mdl2
• foundation-legacy
• jest-serializer-merge-styles
• merge-styles
• public-docsite
• public-docsite-resources
• react
• react-date-time
• react-docsite-components
• react-examples
• react-experiments
• react-file-type-icons
• react-focus
• react-hooks
• scheme-utilities
• set-version
• style-utilities
• test-utilities
• theme-samples
• utilities
• webpack-utilities

Everything else

I updated other packages' beachball configs to keep their current versioning approach, so the only changes should be standard prerelease or patch bumps due to dep version updates.

Environment Information

• Package version(s): ^5.113.1, ^7.6.3, probably 6.x too.
• Browser and OS versions: Windows

Please provide a reproduction of the bug in a codepen:

1. Not a codepen, but a git repo. Check out RushWithMultipleFabricVersions.
2. Run rush install.
3. Run rush build.

Actual behavior:

The build will fail with an error like:

ERROR in C:\Users\hegi\source\repos\test-multiple-react\packages\test-15\src\index.tsx
./src/index.tsx
[tsl] ERROR in C:\Users\hegi\source\repos\test-multiple-react\packages\test-15\src\index.tsx(8,5)
      TS2605: JSX element type 'PrimaryButton' is not a constructor function for JSX elements.
  Type 'PrimaryButton' is missing the following properties from type 'ElementClass': setState, forceUpdate, props, state, and 2 more.

ERROR in C:\Users\hegi\source\repos\test-multiple-react\packages\test-15\src\index.tsx
./src/index.tsx
[tsl] ERROR in C:\Users\hegi\source\repos\test-multiple-react\packages\test-15\src\index.tsx(8,5)
      TS2607: JSX element class does not support attributes because it does not have a 'props' property.

Expected behavior:

The build should succeed. If you open /rush.json and comment out one of the projects, either test-15 or test-16 then the build will succeed on the uncommented project.

Priorities and help requested:

I originally opened Issue 1351 on the Rush team, but @octogonz said it was an issue with phantom dependencies.

Are you willing to submit a PR to fix? No.

Requested priority: Normal

Products/sites affected: Internal development is slower since we can't use rush for projects with multiple UI fabric versions.

I would like a web implementation of a time picker.

I believe that this would be an expansion of the current web DatePicker as the iOS and Android controls are DateTimePickers. https://developer.microsoft.com/en-us/fabric#/controls/web/datepicker

No, I have not discussed this with the team.

Additional context/screenshots https://developer.microsoft.com/en-us/fabric#/controls/ios/date-time-picker https://developer.microsoft.com/en-us/fabric#/controls/android/date-time-picker

Library

React Northstar / v0 (@fluentui/react-northstar)

System Info

System:
    OS: Windows 10 10.0.22621
    CPU: (8) x64 Intel(R) Core(TM) i5-8350U CPU @ 1.70GHz
    Memory: 1004.49 MB / 7.88 GB
  Browsers:
    Edge: Spartan (44.22621.963.0), Chromium (108.0.1462.54)
    Internet Explorer: 11.0.22621.1

Are you reporting Accessibility issue?

yes

Reproduction

https://codepen.io/pen?&prefill_data_id=fc20789b-f43e-4047-8d26-75fbbd6fd252

Bug Description

Actual Behavior

Doesnot close when clicking outside of modal

Expected Behavior

CLose once pressed outside of modal

Logs

No response

Requested priority

Normal

Products/sites affected

No response

Are you willing to submit a PR to fix?

yes

Validations

• [X] Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
• [X] The provided reproduction is a minimal reproducible example of the bug.

Library

React / v8 (@fluentui/react)

System Info

'@fluentui/react/lib/Panel'

Are you reporting Accessibility issue?

no

Reproduction

https://codesandbox.io/s/issue-in-accessing-external-component-but-used-within-panel-rene7m

Bug Description

Actual Behavior

Within Panel component the isBlocking default is set is true, this blocks and do not allow any action on the external component (which may be rendered via reactDom.createPortal to div outside of the Panel component). In my case I am using tinymce editor which opens its modal outside of the Panel.

Also Panel get close as the action happens outside of the Panel. I try to suppress this by event.PreventDefault inside the onDismiss handler, but then it do not propagate the event further inorder for the main actions. Secondly, if I use isBlocking = false, but then dismiss can only be done with the close icon.

Example Link here

Expected Behavior

Can you help me how should I use the Panel as

• Panel to allow the actions outside of the Panel for particular div/divs or which are triggered from components within the Panel components.
• It should dismiss the Panel and onDismiss to be trigger, if I click outside of Panel. and should not trigger dismiss or close if I perform action on elements within external div/divs (like tinymce editor popups) but also allow executes the require actions.

Logs

No response

Requested priority

Blocking

Products/sites affected

No response

Are you willing to submit a PR to fix?

yes

Validations

• [X] Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
• [X] The provided reproduction is a minimal reproducible example of the bug.

Previous Behavior

Two components, Button and ChoiceGroup, directly call the setFocusVisibility function. This defaults to setting the className on the parent <body> tag unless an explicit registeredProviders array is passed in.

This is an issue if the provider ref in the FocusRectsContext is anything other than the <body>, as is the case on our docs site. What happens is the manual call of setFocusVisibility sets the focus-visible className on <body>, while subsequent updates through useFocusRects set it correctly on the element provided in the context. This means there is always a focus-visible className on <body> that never updates, which causes focus to always be visible.

New Behavior

Both components that directly call setFocusVisibility now pass in the registeredProvider from the FocusRectsContext by directly consuming the context within the component.

There isn't really a way to query the context from setFocusVisibility, since it is neither a hook nor a component. Since only two components use it directly, a more involved solution seems like overkill.

Related Issue(s)

Fixes #26030

That issue is about Button, but the same focus visibility issue can be seen in ChoiceGroup in cases where .focus() is called on the component. The example used in this issue (#20173) is a good example of where the focus visibility bug can be seen if the example code is recreated in our latest Fluent version.

Previous Behavior

we have [email protected] in our deps because mdx-js/loader declares it as dependency via exact version. we raised issue on their repo to release patch for v1 which was closed as wont do.

New Behavior

Because mdx-js/loader doesn't enable using proper packages deduping by following semantic versioning principles, which would also enable anyone to resolve deps (patch,minor) on their own, we need to use yarn.resolution to force the behaviours.

Related Issue(s)

• Fixes https://github.com/microsoft/fluentui/issues/26095

Previous Behavior

New Behavior

Implements nx generator that will migrate @fluentui/scripts to separate packages and update devDeps in whole monorepo

Related Issue(s)

• Fixes partially https://github.com/microsoft/fluentui/issues/24349