V12

.claude/commands/commit.md

@@ -7,6 +7,7 @@ Create a commit following the Instructure UI commit conventions:
 ## Format Requirements
 
 Use Conventional Commits format:
+
 ```
 type(scope): subject
 
@@ -25,13 +26,15 @@ Document any breaking changes here with BREAKING CHANGE: prefix
 ## Breaking Changes
 
 Mark breaking changes with an exclamation mark after scope and document in body:
+
 ```
 feat(ui-select)!: remove deprecated onOpen prop
 
 BREAKING CHANGE: The onOpen prop has been removed. Use onShowOptions instead.
 ```
 
 Breaking changes include:
+
 - Removing/renaming props or components
 - Changing prop types or behavior
 - Changing defaults that affect behavior
@@ -40,6 +43,7 @@ Breaking changes include:
 ## Commit Footer
 
 Always include:
+
 ```
 🤖 Generated with [Claude Code](https://claude.com/claude-code)
 

.claude/commands/pr.md

@@ -28,23 +28,27 @@ All PRs must include:
 6. **If Jira ticket number is unknown, ask the user for it before creating the PR**
 7. Push to remote if needed: `git push -u origin <branch>`
 8. Create PR with `gh pr create --title "title" --body "$(cat <<'EOF'
+
 ## Summary
+
 - Bullet point 1
 - Bullet point 2
 
 ## Test Plan
+
 - [ ] Step 1
 - [ ] Step 2
 
 ## Jira Reference
+
 Fixes INST-XXXX (or omit this section if not applicable)
 
 🤖 Generated with [Claude Code](https://claude.com/claude-code)
 EOF
-)"`
-9. Return the PR URL
+)"` 9. Return the PR URL
 
 **Important**:
+
 - Base branch is usually `master` (not main)
 - Analyze ALL commits in the branch, not just the latest one
 - Use markdown checklists for test plan

.github/workflows/preview.yml

@@ -12,6 +12,8 @@ on:
 jobs:
   deploy-preview:
     runs-on: ubuntu-latest
+    env:
+      GITHUB_PULL_REQUEST_PREVIEW: 'true'
     steps:
       - uses: actions/checkout@v4
       - uses: pnpm/action-setup@v4

.husky/prepare-commit-msg

@@ -6,7 +6,9 @@ if [ "$2" = "commit" ] && [ -n "$3" ]; then
 fi
 
 # Check if a rebase is in progress
-if [ -d ".git/rebase-merge" ] || [ -d ".git/rebase-apply" ]; then
+if [ -d "$(git rev-parse --git-path rebase-merge)" ] ||
+   [ -d "$(git rev-parse --git-path rebase-apply)" ]; then
+  echo "Skipping prepare-commit-msg git hook during rebase"
   exit 0
 fi
 

.inst-ai/templates/jira/README.md

@@ -5,10 +5,12 @@ This directory contains prompt templates for generating Jira tickets from Slack
 ## Template Types
 
 ### Bug Report Templates
+
 - `bug-report.extraction.md` - Extracts structured data from bug report conversations
 - `bug-report.generation.md` - Generates final Jira ticket content for bugs
 
 ### Feature Request Templates
+
 - `feature-request.extraction.md` - Extracts structured data from feature request conversations
 - `feature-request.generation.md` - Generates final Jira ticket content for features
 
@@ -42,4 +44,4 @@ export const config = {
 
 ## Template Format
 
-Templates should be valid Markdown files with embedded prompts for the AI model. The AI will process the template content and generate responses in the expected format (JSON for extraction, ADF JSON for generation).
+Templates should be valid Markdown files with embedded prompts for the AI model. The AI will process the template content and generate responses in the expected format (JSON for extraction, ADF JSON for generation).

.inst-ai/templates/jira/bug-report.extraction.md

@@ -3,10 +3,11 @@
 **Task:** Analyze the conversation and extract entities into a JSON object. Use `null` for missing values.
 
 **Entities:**
+
 - `component_name`: string | null - The name of the UI component or module mentioned
 - `browser_name`: string | null - Browser where the issue occurs (e.g., "Chrome", "Firefox", "Safari")
 - `os_name`: string | null - Operating system where the issue occurs (e.g., "macOS", "Windows", "Linux")
-- `instui_version`: string | null - InstUI version (e.g., "8.51.0", "v8.51.0"). Look for @instructure/ui-* package versions in package.json, version mentions in conversation, or CodeSandbox dependencies
+- `instui_version`: string | null - InstUI version (e.g., "8.51.0", "v8.51.0"). Look for @instructure/ui-\* package versions in package.json, version mentions in conversation, or CodeSandbox dependencies
 - `summary_of_bug`: string - Brief description of the bug
 - `reporter_name`: string - Name of the person reporting the bug
 - `environment_text`: string | null - Additional environment details
@@ -18,4 +19,4 @@
 **Conversation:**
 {{CONVERSATION_CONTENT}}
 
-**JSON Output:**
+**JSON Output:**

.inst-ai/templates/jira/bug-report.generation.md

@@ -5,6 +5,7 @@
 **Task:** Use the `CONTEXT` to generate a JSON object with a `summary` and an ADF `description`.
 
 **Requirements:**
+
 - The `summary` must be: `Fix: [<Component Name>] <Brief problem description>`. Use the component_name from extracted data if available, otherwise use a generic name based on the affected area.
 - The `description` must be a valid Atlassian Document Format (ADF) JSON object.
 - Include all relevant technical details from the context.
@@ -24,4 +25,4 @@
 
 **Your Turn (Use the CONTEXT provided above):**
 **IMPORTANT:** Return ONLY valid JSON. Every property must be followed by a comma except the last one in an object or array. Double-check all commas before responding.
-**Output JSON:**
+**Output JSON:**

.inst-ai/templates/jira/feature-request.extraction.md

@@ -3,6 +3,7 @@
 **Task:** Analyze the conversation and extract entities into a JSON object. Use `null` for missing values.
 
 **Entities:**
+
 - `feature_name`: string | null - The name of the requested feature
 - `requestor_name`: string - Name of the person requesting the feature
 - `business_justification`: string | null - Why this feature is needed
@@ -15,4 +16,4 @@
 **Conversation:**
 {{CONVERSATION_CONTENT}}
 
-**JSON Output:**
+**JSON Output:**

.inst-ai/templates/jira/feature-request.generation.md

@@ -5,6 +5,7 @@
 **Task:** Use the `CONTEXT` to generate a JSON object with a `summary` and an ADF `description`.
 
 **Requirements:**
+
 - The `summary` must be: `Feature: [<Component/Area Name>] <Brief description>`. Use the feature_name or affected_components from extracted data if available, otherwise use a generic name based on the affected area.
 - The `description` must be a valid Atlassian Document Format (ADF) JSON object.
 - Include business justification, proposed solution, and success criteria.
@@ -24,4 +25,4 @@
 
 **Your Turn (Use the CONTEXT provided above):**
 **IMPORTANT:** Return ONLY valid JSON. Every property must be followed by a comma except the last one in an object or array. Double-check all commas before responding.
-**Output JSON:**
+**Output JSON:**

CLAUDE.md

@@ -53,6 +53,7 @@ pnpm run build:types  # Build TypeScript declarations
 
 # Testing
 pnpm run test:vitest  # Unit tests
+pnpm run test:vitest ui-radio-input # Run tests for a single package
 pnpm run cy:component # Cypress component tests
 
 # Linting
@@ -152,6 +153,7 @@ All components **MUST**:
 ```bash
 pnpm run test:vitest  # Unit tests
 pnpm run cy:component # Cypress tests
+pnpm run test:vitest ui-radio-input # Run tests for a single package
 
 # Visual regression tests (in regression-test directory)
 cd regression-test

cypress/component/Menu.cy.tsx

@@ -270,7 +270,8 @@ describe('<Menu/>', () => {
       .should('be.focused')
   })
 
-  it(`should show and focus flyout menu on space keyDown`, () => {
+  // This test is failing randomly
+  it.skip(`should show and focus flyout menu on space keyDown`, () => {
     cy.mount(
       <Menu label="Parent">
         <Menu label="Flyout">

cypress/component/Pagination.cy.tsx

@@ -99,7 +99,7 @@ describe('<Pagination/>', () => {
       })
     })
 
-    cy.viewport(300, 800)
+    cy.viewport(100, 800)
 
     cy.get('[role="navigation"]').within(() => {
       cy.get('button').then(($items) => {

docs/contributor-docs/migrating-to-new-tokens.md

@@ -0,0 +1,35 @@
+---
+title: Migrating components to new theming system
+category: Contributor Guides
+order: 01
+---
+
+# Token migration
+
+The new token system consists of auto-generated tokens form design. They can be imported from `ui-themes`.
+
+## Changing tokens only
+
+The migration strategy with the least amount of effort is only changing tokens. This approach keeps the component as class-based and retains the `View` component.
+
+Changes needed:
+
+- Import token types from `@instructure/ui-themes` instead of `@instructure/shared-types`
+- Update `generateStyle` function to use `NewComponentTypes['ComponentName']` for the theme parameter
+- Replace old theme tokens with new token names from the design system
+- Replace `@withStyleRework` decorator with `@withStyle` and remove `generateComponentTheme`
+- delete `theme.ts`
+
+If tokens are from a different (usually parent) components, add the `componentID` of that component as second paramater of `@withStyle` and use that name in the `generateStyle` function in `style.ts`: `NewComponentTypes['ParentComponentNameWithTheTokens']`
+
+`generateStyle` accepts a third parameter as well, which are the `sharedTokens`. These provide tokens for shared behaviors such as focus rings, shadows or margins. `'@instructure/emotion'` has various util functions that uses these, such as `calcMarginFromShorthand` and `calcFocusOutlineStyles`.
+
+## Removing View
+
+For some components it makes sense to remove the `View` component underneath the component structure. Most of the time, `View` only provides margins, focus rings, or minor visual aid. These can be replicated - in most cases - by the `sharedTokens` and their utils.
+
+Ideally all occurrences of `View` would be eliminated from the codebase.
+
+## Transforming class based components to functional
+
+The ultimate goal is to migrate all components to functional based ones. Currently it's not a priority and detailed migration guides will be available later. For the time being, `Avatar` or `RadioInput` can be used as starting reference points.

docs/guides/form-errors.md

@@ -15,7 +15,6 @@ type: code
 ---
 type FormMessages = {
   type:
-    | 'newError'
     | 'error'
     | 'hint'
     | 'success'
@@ -33,7 +32,7 @@ type: example
 const PasswordExample = () => {
   const [password, setPassword] = useState('')
   const messages = password.length < 6
-    ? [{type: 'newError', text: 'Password have to be at least 6 characters long!'}]
+    ? [{type: 'error', text: 'Password have to be at least 6 characters long!'}]
     : []
   return (
     <TextInput
@@ -48,11 +47,9 @@ const PasswordExample = () => {
 render(<PasswordExample/>)
 ```
 
-However you might have noticed from the type definition that a message can be `error` and `newError` type. This is due to compatibility reasons. `error` is the older type and does not meet accessibility requirements, `newError` (hance the name) is the newer and more accessible format.
+The `error` type has been updated to meet accessibility requirements with proper icons and visual styling. Previously, there was a `newError` type that provided this enhanced behavior, but it has been consolidated into the standard `error` type for consistency. `newError` has been deprecated.
 
-We wanted to allow users to start using the new format without making it mandatory, but after the introductory period `newError` will be deprecated and `error` type will be changed to look and behave the same way.
-
-With this update we also introduced the "required asterisk" which will display an `*` character next to field labels that are required. This update is not opt-in and will apply to **all** InstUI form components so if you were relying on a custom solution for this feature before, you need to remove that to avoid having double asterisks.
+We also introduced the "required asterisk" which displays an `*` character next to field labels that are required. This update applies to **all** InstUI form components, so if you were relying on a custom solution for this feature before, you need to remove that to avoid having double asterisks.
 
 Here are examples with different form components:
 
@@ -62,17 +59,15 @@ type: example
 ---
 const Example = () => {
   const [showError, setShowError] = useState(true)
-  const [showNewError, setShowNewError] = useState(true)
   const [showLongError, setShowLongError] = useState(false)
   const [isRequired, setIsRequired] = useState(true)
 
   const messages = showError
-    ? [{type: showNewError ? 'newError' : 'error', text: showLongError ? 'Long error. Lorem ipsum dolor sit amet consectetur adipisicing elit. Dignissimos voluptas, esse commodi eos facilis voluptatibus harum exercitationem. Et magni est consectetur, eveniet veniam unde! Molestiae labore libero sapiente ad ratione.' : 'Short error message'}]
+    ? [{type: 'error', text: showLongError ? 'Long error. Lorem ipsum dolor sit amet consectetur adipisicing elit. Dignissimos voluptas, esse commodi eos facilis voluptatibus harum exercitationem. Et magni est consectetur, eveniet veniam unde! Molestiae labore libero sapiente ad ratione.' : 'Short error message'}]
     : []
 
   const handleSettingsChange = (v) => {
     setShowError(v.includes('showError'))
-    setShowNewError(v.includes('showNewError'))
     setShowLongError(v.includes('showLongError'))
     setIsRequired(v.includes('isRequired'))
   }
@@ -83,10 +78,9 @@ const Example = () => {
         name="errorOptions"
         description="Error message options"
         onChange={handleSettingsChange}
-        defaultValue={['showError', 'showNewError', 'isRequired']}
+        defaultValue={['showError', 'isRequired']}
       >
         <Checkbox label="Show error message" value="showError"/>
-        <Checkbox label="Use the new error type" value="showNewError" />
         <Checkbox label="Use long message" value="showLongError" />
         <Checkbox label="Make fields required" value="isRequired" />
       </CheckboxGroup>