|
| 1 | +--- |
| 2 | +title: Component versioning |
| 3 | +category: Guides |
| 4 | +order: 5 |
| 5 | +--- |
| 6 | + |
| 7 | +## Why components are versioned |
| 8 | + |
| 9 | +When InstUI needs to make a breaking change to a component (renamed props, changed behaviour, etc.), the old version is **kept alongside the new one** instead of being replaced. Upgrading the library no longer forces you to immediately rewrite every component usage — you can migrate to new versions on your own schedule. |
| 10 | + |
| 11 | +New component versions appear with InstUI **minor** version bumps (e.g. `11.7` → `11.8`). Patch releases never include breaking changes. |
| 12 | + |
| 13 | +## Import paths |
| 14 | + |
| 15 | +Every InstUI component package supports three import styles: |
| 16 | + |
| 17 | +### Default — `@instructure/ui-<name>` |
| 18 | + |
| 19 | +Always points to the **oldest** still-supported component version. Upgrading the library without changing your imports will keep your code working without surprises. |
| 20 | + |
| 21 | +```js |
| 22 | +--- |
| 23 | +type: code |
| 24 | +--- |
| 25 | +import { Alert } from '@instructure/ui-alerts' |
| 26 | +``` |
| 27 | + |
| 28 | +### Pinned — `@instructure/ui-<name>/v11_X` |
| 29 | + |
| 30 | +Locks the import to a specific InstUI minor version of the component. When you are ready to adopt a breaking change, update the path to the next pinned version. |
| 31 | + |
| 32 | +```js |
| 33 | +--- |
| 34 | +type: code |
| 35 | +--- |
| 36 | +import { Alert } from '@instructure/ui-alerts/v11_7' |
| 37 | +``` |
| 38 | + |
| 39 | +### Latest — `@instructure/ui-<name>/latest` |
| 40 | + |
| 41 | +Always points to the newest component version. This may bring breaking changes when you upgrade InstUI itself. |
| 42 | + |
| 43 | +```js |
| 44 | +--- |
| 45 | +type: code |
| 46 | +--- |
| 47 | +import { Alert } from '@instructure/ui-alerts/latest' |
| 48 | +``` |
| 49 | + |
| 50 | +### Per-package or umbrella package |
| 51 | + |
| 52 | +InstUI also ships an umbrella package, `@instructure/ui`, which re-exports every component from the individual `@instructure/ui-*` packages. Two equivalent import styles work — both resolve to the same component: |
| 53 | + |
| 54 | +```js |
| 55 | +--- |
| 56 | +type: code |
| 57 | +--- |
| 58 | +// per-package import |
| 59 | +import { Alert } from '@instructure/ui-alerts/v11_7' |
| 60 | + |
| 61 | +// umbrella package import |
| 62 | +import { Alert } from '@instructure/ui/v11_7' |
| 63 | +``` |
| 64 | + |
| 65 | +The same three path styles (default / `/v11_X` / `/latest`) work on the umbrella package as well. Pick per-package imports when you want better tree-shaking and only pull in what you use, or the umbrella package when you'd rather depend on a single `@instructure/ui` entry in your `package.json`. |
| 66 | + |
| 67 | +## Versions and theming engines |
| 68 | + |
| 69 | +InstUI is in the middle of a transition between two theming systems. Which engine a component uses depends on which version you import: |
| 70 | + |
| 71 | +- **`v11_6` and earlier** — legacy theming. Components are configured through the Canvas theme variables and the `themeOverride` prop, which accepts a function or object that maps to the component's own theme map. See the [Legacy theme overrides](legacy-theme-overrides) guide. |
| 72 | + |
| 73 | +- **`v11_7` and newer** — new theming system. Components consume pre-resolved design tokens, and theming is done through the new token override structure. See the [New theme overrides](new-theme-overrides) guide. |
| 74 | + |
| 75 | +Mixing imports from both groups in the same app is fully supported — the two engines run side-by-side without conflict. |
| 76 | + |
| 77 | +### Supported themes per version |
| 78 | + |
| 79 | +Each version of the library is only compatible with the themes built for its theming engine: |
| 80 | + |
| 81 | +- **`v11_6` and earlier** support the legacy themes: |
| 82 | + |
| 83 | + - `canvas` |
| 84 | + - `canvasHighContrast` |
| 85 | + |
| 86 | +- **`v11_7` and newer** support themes built on the new token system. The legacy Canvas looks are preserved (re-implemented on the new engine) and two brand-new themes are added: |
| 87 | + |
| 88 | + - `legacyCanvas` — same visual style as the old `canvas`, but on the new engine |
| 89 | + - `legacyCanvasHighContrast` — same visual style as the old `canvasHighContrast`, on the new engine |
| 90 | + - `light` — new light theme |
| 91 | + - `dark` — new dark theme |
| 92 | + |
| 93 | +This means that when you move a component import from `/v11_6` to `/v11_7` you don't have to change anything visually — you can stay on the `legacyCanvas` theme and opt in to `light` or `dark` only when you're ready. |
0 commit comments