@tarviks/fluentui9

Personal npm mirror of @capsitech/fluentui9, used to iterate quickly without cutting a release in the main Capsitech repo on every change.

This is a temporary workspace. Once the API stabilizes, the code here should be copied back into Capsitech.FluentUIComponentsV9 as-is and published as @capsitech/fluentui9 from there. See DX-ROADMAP.md for the in-progress checklist of what "stable enough to move" means, component by component.

Quickstart

Every component requires AOFluentProviderV9 as an ancestor — it supplies theme tokens and the portal mount node that Popover/Dialog/Menu render into.

import { AOFluentProviderV9, PrimaryButton } from '@tarviks/fluentui9';

function App() {
  return (
    <AOFluentProviderV9>
      <PrimaryButton onClick={() => console.log('clicked')}>Click me</PrimaryButton>
    </AOFluentProviderV9>
  );
}

Every component ships its own Storybook story and .docs.mdx page under src/Components/<Name>/ — run yarn start and browse Components/ for the full catalog and live-editable examples.

Components

Button (Default/Primary/Icon/Action/CommandBar/Compound/Menu/Split, plus Danger/Success/Warning/Confirm variants), AudioPlayer, ColorPicker, CommandBar, ContentEditorComponent (rich text editor), DatePicker / DateRangePicker, FileComponents, Loading (FullPageSpinner, LoadingStack, LoadingOverlay), Modal (plain + Formik-integrated), Nav, Notification, Pagination, Panel (plain + Formik-integrated), Picker, QueryBuilder, Resizer, Stats, SubwayNav, Toast, Wizard.

No DataGrid/DetailsList equivalent exists yet — any screen with a v8 DetailsList-based table can't fully migrate to v9 without keeping the table itself on v8. Worth a table/data-grid wrapper if that becomes a blocker for a real migration.

Versioning

This package follows Semantic Versioning (MAJOR.MINOR.PATCH), with the standard semver rule for a pre-1.0 package (currently 0.1.x): MAJOR stays 0 until the public API (component props, exports, AOFluentProviderV9) is considered stable enough for another team to depend on without expecting frequent breaking changes. Until then:

| Bump | When | Example | |---|---|---| | PATCH (0.1.5 → 0.1.6) | Bug fixes, internal refactors, test/docs/infra-only changes, or a backward-compatible addition (new optional prop, new component) that doesn't change any existing behavior. | Fixing a broken ref, adding a new optional prop, tightening a type that was already correct at the value level. | | MINOR (0.1.x → 0.2.0) | Anything a consumer's existing code could break on: a prop's type or default behavior changes, a prop or export is removed, a component's rendered output changes in a way that could break someone's styling/tests. Per semver's own spec for 0.y.z, breaking changes bump y (MINOR), not x (PATCH) — don't ship a breaking change as a patch just because the fix itself is small. | Removing a deprecated prop, changing what onChange passes as its argument, renaming an export. | | MAJOR (0.x.y → 1.0.0) | Reserved for the one-time move to declaring the API stable — not used for ordinary breaking changes while still in 0.x. After 1.0.0, standard semver applies in full: MAJOR for breaking changes, MINOR for backward-compatible features, PATCH for backward-compatible fixes. | — |

Before publishing: update CHANGELOG.md's [Unreleased] section with what actually changed — this is how the next person (including future-you) answers "what's actually in 0.1.6" without reading git log. See CONTRIBUTING.md for the full pre-release checklist.

Picking the right script — build:publish (alias for build:publish:patch) is the default; use the explicit variant when a change is MINOR/MAJOR per the table above:

yarn build:publish:patch # (or plain `yarn build:publish`) — bug fixes, non-breaking additions
yarn build:publish:minor # breaking change while still pre-1.0
yarn build:publish:major # the one-time jump to 1.0.0 once the API is declared stable

Each runs the test suite, bumps the version via npm version, builds, and publishes — in that order, so a failing test or build never reaches the registry.

Publishing (run locally, under your own npm login)

npm login           # once, stores your token locally — never share it
yarn install
yarn build:publish   # see "Versioning" above for which script to actually run

Known gotcha: multiple @fluentui/react-motion versions in your app tree

If your app throws presenceFn is not a function (or similar) at runtime, it means your dependency tree resolved more than one copy of @fluentui/react-motion — usually because some other package in your app also depends on @fluentui/react-components/@fluentui/react-dialog at a different version, and each pulls its own react-motion that your package manager didn't dedupe. This package now depends on exact (non-^) versions of its @fluentui/react-* dependencies specifically to reduce how often this happens, but a library's own resolutions/overrides field only applies when that library is the workspace root — once installed as a dependency of your app, it's ignored. If you still hit this, add the same pin to your app's root package.json:

// Yarn
"resolutions": {
  "@fluentui/react-motion": "9.16.1"
}

// npm / pnpm
"overrides": {
  "@fluentui/react-motion": "9.16.1"
}

Match the version to whatever @fluentui/react-components this package currently depends on (see dependencies in this package's package.json), and re-run install.