feat(many): instUI v11 release

many new changes
removal of propTypes

BREAKING CHANGE: - remove propTypes
- remove CodeEditor

Author: matyasf

.github/workflows/visual-regression.yml

@@ -23,7 +23,8 @@ jobs:
         env:
           ELECTRON_EXTRA_LAUNCH_ARGS: "--remote-debugging-port=9222"
         with:
-          start: npm run dev
+          build: npm run build
+          start: npm start
           working-directory: regression-test
       - name: Upload cypress artifact for chromatic
         uses: actions/upload-artifact@v4
@@ -43,7 +44,7 @@ jobs:
           fetch-depth: 0
       - uses: actions/setup-node@v4
         with:
-          node-version: 22.12.0
+          node-version: 22
       - name: Install dependencies
         run: npm ci
         working-directory: regression-test

README.md

@@ -12,11 +12,7 @@ Instructure UI is an open source UI framework and design system for React. Its c
 
 ## Contributing
 
-Before contributing please read our [code of conduct](https://instructure.design/#CODE_OF_CONDUCT) and read the [contribution guidelines](https://instructure.design/#contributing).
-
-## React Support
-
-Instructure UI currently supports 16.14.0 and higher.
+Before contributing, please read our [code of conduct](https://instructure.design/#CODE_OF_CONDUCT) and read the [contribution guidelines](https://instructure.design/#contributing).
 
 ## Browser Support
 

cypress/component/Emotion-withStyle.cy.tsx

@@ -29,7 +29,6 @@ import {
   WithStyleProps,
   withStyle
 } from '@instructure/emotion/src/index'
-import PropTypes from 'prop-types'
 
 import '../support/component'
 import 'cypress-real-events'
@@ -102,10 +101,6 @@ const generateStyle = function (
 
 @withStyle(generateStyle, generateComponentTheme)
 class ThemeableComponent extends Component<Props, State> {
-  static propTypes = {
-    inverse: PropTypes.bool
-  }
-
   static defaultTypes = {
     inverse: false
   }

docs/contributor-docs/api-guidelines.md

@@ -10,43 +10,42 @@ order: 4
 
 - All components should pass through additional props down to the root DOM element using the `passthroughProps` utility. (e.g. `<div {...passthroughProps(this.props)}>`). Note that in addition to allowing only valid DOM node attributes, `passthroughProps` will remove the `className` and `style` props to prevent unexpected style issues. These need to be set explicitly and used with caution. It also removes the `styles` and `makesStyles` properties added by the [withStyle](#withStyle) decorator.
 - Avoid props that could be computed from other props. (e.g. prefer `<Select filter={handleFilter} />` over `<Select shouldFilter filter={handleFilter} />`. Prefer determining whether filtering should happen based on the presence of the `filter` function prop.)
-- Avoid situations where certain prop combinations are not supported. Prefer splitting the component into separate components with fewer props or using `PropTypes.oneOf`.
+- Avoid situations where certain prop combinations are not supported. Prefer splitting the component into separate components with fewer props.
 - Set default prop values for non-required props when possible.
 
 #### General Naming Conventions
 
 - Component prop names should be camelCase.
 - Avoid the 'default' prop prefix since all components should be controlled only.
 - If the component should allow custom DOM elements, it should provide an `as` prop. (e.g. `<Tag as="span" />` will render an HTML `span` element.)
-- Enum (`PropType.oneOf`) prop values should be kebab-case (dashes) (e.g. `size="x-small"`).
+- Enum prop values should be kebab-case (dashes) (e.g. `size="x-small"`).
 
 #### Boolean props
 
-- Boolean props should be avoided when possible in favor of `PropTypes.oneOf` (a list of possible values) so that it's easier to extend later on.
-- Avoid Boolean props that are mutually exclusive in favor of `PropTypes.oneOf` or separate components. For example, prefer `<Input interaction="disabled" />` over `<Input disabled />` where the `interaction` prop is `PropTypes.oneOf(['disabled', 'enabled', 'readonly'])`. Note that an input cannot be disabled and readonly, so these are mutually exclusive.
+- Avoid Boolean props that are mutually exclusive in favor of separate components. For example, prefer `<Input interaction="disabled" />` over `<Input disabled />` where the `interaction` prop is `'disabled' | 'enabled' | 'readonly'`. Note that an input cannot be disabled and readonly, so these are mutually exclusive.
 - Boolean props should begin with `should`/`is`/`does`/`has`/`with`.
 - When possible, default boolean props to `false` so that they can be set to `true` without a value. (e.g. prefer `<Modal isOpen />` over `<Modal isClosed={false} />`)
 
 #### Function props
 
-- Function props that provide custom rendering should be prefixed with `render` (e.g. `renderLabel`, `renderHeader`). These props can be set to `PropTypes.oneOfType([PropTypes.node, PropTypes.func])` for the most flexibility. If your prop only accepts strings and provides text that is only read by screen readers, use the `screenReader` prefix (e.g., `screenReaderLabel`).
+- Function props that provide custom rendering should be prefixed with `render` (e.g. `renderLabel`, `renderHeader`). If your prop only accepts strings and provides text that is only read by screen readers, use the `screenReader` prefix (e.g., `screenReaderLabel`).
 - Function props that handle events should be prefixed with `on` (e.g. `onDismiss`, `onClose`, `onSelect`).
 - Function props that handle DOM events should always pass in the [React SyntheticEvent](https://reactjs.org/docs/events.html) object as the first argument and any meta data about the event as a second argument.
 - Function props that handle DOM events should be chained (e.g. `createChainedFunction(this.props.onFocus, this.handleFocus)`) so that consumers are able to attach their own handlers in addition to the built in handlers.
 - Function [ref](https://reactjs.org/docs/refs-and-the-dom.html) props should have a `Ref` suffix and should describe the element to which it provides a ref (e.g. `inputRef`).
-- All components should provide an `elementRef` prop that will return a ref to the root DOM element.
+- All components should provide an `ref` prop that will return a ref to the root DOM element.
 
 #### Children
 
 - Prefer child components and composition with JSX vs. complex prop types. (e.g. prefer `<List><List.Item label="foo" /></List>` over `<List items={['foo']} />`)
 - Avoid using internal child components that aren't meant to be exported as part of the public component API. Prefer composition using other publicly available components that can be rendered in isolation or provide public child components.
 - If your component accepts a list of children, make sure it handles `null` children.
-- Child components that can't be used on their own should be exported as static properties on the parent component (e.g. `Table.Row`, `Menu.Item`), so that only one import is required to render the component (e.g. `import Table from '@instructure/ui-tables'`).
+- Child components that can't be used on their own should be exported as static properties on the parent component (e.g. `Table.Row`, `Menu.Item`), so that only one import is required to render the component (e.g. `import Table from '@instructure/ui-table'`).
 - If the parent component can only be used with specific children that can also be used on their own, it should have the `Group` suffix (e.g. `<RadioGroup><Radio /><Radio /></RadioGroup>`, `<ButtonGroup><Button /><Button /></ButtonGroup>`).
 
-### styles.js Class Names
+### styles.ts Class Names
 
-- In the `styles.js`, use the name of the component in camelCase (e.g. `appNav`) as the key of the root element's style object. Use camelCase for the keys of child elements as well (e.g. `list` and `listItem`).
+- In the `styles.ts`, use the name of the component in camelCase (e.g. `appNav`) as the key of the root element's style object. Use camelCase for the keys of child elements as well (e.g. `list` and `listItem`).
 - All style object names should be semantic (describe the content, not what it looks like).
 - We make use of the `label` property of [Emotion.js](https://emotion.sh/) so that it gets displayed in the generated class name for easy readability and targetability. We use a naming convention based on [BEM naming convention](#http://getbem.com/naming/):
   - For the root element, add a label with the name of the component in camelCase \

docs/contributor-docs/codemods.md

@@ -70,8 +70,8 @@ We support testing these warnings using special fixtures and a console.warn spy.
    ---
    <MyComponent deprecatedProp="value" />
    ```
-3. Create new sample output file with the array of expected warning messages in the `__testfixtures__` folder, filename follows the following naming convention: `[fixtureName].warning.output.[js/ts/tsx]`:
-   ```ts
+3. Create new sample output file with the array of expected warning messages in the `__testfixtures__` folder, filename follows the following naming convention: `[fixtureName].warning.output.json`:
+   ```json
    ---
    type: code
    ---

docs/contributor-docs/contributing.md

@@ -28,7 +28,7 @@ Please follow the steps on the [how to build guide page](#building-instui).
 ### Running the documentation app
 
 1. Run `npm start`
-1. Open [http://localhost:8001](http://localhost:8001) in your browser
+1. Open [http://localhost:9090](http://localhost:9090) in your browser
 
 ### Development
 
@@ -41,73 +41,29 @@ Please follow the steps on the [how to build guide page](#building-instui).
 
 ### Testing
 
-See the [testing documentation](#testing-components) for details.
+See the [testing documentation](#testing-overview) for details.
 
 ### Linters and Code Formatting
 
-Linters are run as part of the build. If you use the Sublime Text, Atom, or VSCode editors, you can set up the following plugins to catch lint and formatting errors earlier.
+Linters are run as part of the build. If you use VSCode, you can set up the following plugins to catch lint and formatting errors earlier.
 
-1. Install the _Linter_ plugin [Sublime](http://sublimelinter.readthedocs.org/en/latest/), [Atom](https://atom.io/packages/linter). Linting is included in VSCode.
-1. Install the _EditorConfig_ plugin [Sublime](https://github.com/sindresorhus/editorconfig-sublime), [Atom](https://github.com/sindresorhus/atom-editorconfig), [VSCode](https://github.com/editorconfig/editorconfig-vscode)
-1. Install the _Eslint_ plugin [Sublime](https://github.com/roadhump/SublimeLinter-eslint), [Atom](https://github.com/AtomLinter/linter-eslint), [VSCode](https://github.com/Microsoft/vscode-eslint)
-1. Install the _Stylelint_ plugin [Sublime](https://github.com/kungfusheep/SublimeLinter-contrib-stylelint), [Atom](https://atom.io/packages/linter-stylelint), [VSCode](https://github.com/shinnn/vscode-stylelint)
+1. Install the _Eslint_ plugin [VSCode](https://github.com/Microsoft/vscode-eslint)
+1. Install the _Stylelint_ plugin [VSCode](https://github.com/stylelint/vscode-stylelint)
 1. Run `npm install` to install the dependencies
 1. Restart your editor
 
 ### Documentation
 
 Please update the documentation and examples with any changes.
 
-- `npm start` will build the production version of the documentation. You can view it at [http://localhost:8001](http://localhost:8001).
+- `npm start` will build the production version of the documentation. You can view it at [http://localhost:9090](http://localhost:9090).
 - All components and utilities should be well documented, including examples.
 - Write documentation inline in code comment blocks. The code and docs should
   always be in sync.
 
 ### Commit Guidelines
 
-1. Run `git commit` to commit your changes and follow our commit message format.
-1. Please do not include the output of `npm run build` in your commits.
-
-### Adding a package
-
-1. Run `npm run generate:package` and choose a name for your package (use "kebab" case (dashes), e.g. 'my-package').
-2. Run `npm install` to update the lockfile.
-3. Give a new package `description` in the `package.json` file.
-4. Add package reference in the root `tsconfig.references.json`.
-5. Register your package in the **docs app**:
-   1. Add an alias for your package in `packages/__docs__/resolve.js`.
-   2. Add the dependency in `packages/__docs__/package.json`.
-   3. Add the reference in `packages/__docs__/tsconfig.build.json`.
-6. Stop the dev server (if you have it running), and run `npm run dev` to pick up the new package.
-7. Visit [http://localhost:9090](http://localhost:9090) in a browser. You should see your package listed in the docs.
-
-### Adding a component
-
-1. Run `npm run generate:component` and choose a name for your component (use Pascal case: e.g., 'MyComponent').
-2. Choose to create a new package for your component, add it to an existing package, or create the component with no package.
-3. If you added the component to an **existing package**:
-   1. Don't forget to [add the new dependencies and devDependencies](/#contributing/#code-guidelines-adding-a-new-dependency) to the package.
-   2. List the new component in the package's `README.md` file under the `### Components` title (use other packages as reference when there is no "Components" block yet).
-   3. Export the component from the `packages/[package]/src/index.js` (`export { MyComponent } from './MyComponent'`)
-   4. Export the "Props type" from the `packages/[package]/src/index.js` (`export type { MyComponentProps } from './MyComponent/props'`)
-4. If you created a **new package** for your component:
-   1. Follow the setup steps 2-5 of [Adding a package](/#contributing/#code-guidelines-adding-a-package). Do not start the dev server yet.
-   2. The exports for the component and its Props type will be added automatically to `packages/[package]/src/index.js`.
-5. When adding a child component to another component, modify the child's `componentId` to be prefixed with the parent, e.g.: `MyComponent.Item`.
-6. [Register the components Theme type](/#contributing/#code-guidelines-registering-the-components-theme-type). For the initial setup, define the mock variables used in the `theme.js`.
-7. Run `npm install` to update the lockfile.
-8. Run `npm run bootstrap` to generate the `es`, `lib` and `types` directories for your component.
-9. Add your component to `packages/__docs__/components.js`.
-10. Stop the dev server (if you have it running), and run `npm run dev` to pick up the new component.
-11. Visit [http://localhost:9090](http://localhost:9090) in a browser. You should see your component listed in the docs.
-12. Start making changes to your component, and watch it update in the browser automatically.
-13. Resolve all `FIXME` comments in the generated code (except in the `MyComponentLocator.ts`).
-14. Add a short description of the new component to the `packages/__docs__/buildScripts/ai-accessible-documentation/summaries-for-llms-file.json` file. This will optimize the component's documentation for consumption by AI agents.
-
-### Adding a new dependency
-
-1. Add the new dependency or devDependency in the package's `package.json`.
-2. If the dependency is one of our own `@instructure/` packages, add it to the type references in the package's `tsconfig.build.json` too.
+Run `git commit` to commit your changes and follow our commit message format.
 
 ### Registering the components Theme type
 

docs/contributor-docs/release.md

@@ -152,7 +152,11 @@ git push origin release
 
 Major version updates are very similar to minor updates but there are a couple additinal things to take care of.
 
-##### 1. Create a maintenance branch
+##### 1. Write an upgrade guide
+
+Update `upgrade-guide.md` with the new major version and the breaking changes.
+
+##### 2. Create a maintenance branch
 
 Before the update, create a maintenance branch from the current master and push it to remote. If the current major version is 11, then:
 
@@ -164,17 +168,16 @@ git checkout -b v11_maintenance
 git push origin v11_maintenance
 ```
 
-##### 2. Update the version mapping for the docs
+##### 3. Update the version mapping for the docs
 
 Update the fields in the file `./packages/__docs__/versions.json` with the latest version and the maintenance branch map. Remove old unsupported versions if they are no longer needed and you don't want them to appear in the docs page version selector.
 
-##### 3. Update version references in the docs app
+##### 4. Update version references in the docs app
 
 1. In `docs/getting-started/usage.md` update the version in the code snippet for `package.json`
-2. In `packages/__docs__/src/Hero/index.tsx` update the url and title of the Upgrade Guide button
-3. In `packages/__docs__/src/Hero/index.tsx` update the url and title of the Upgrade Guide link in the "What's new?" section
-4. In `packages/__docs__/src/CodeSandboxButton/index.tsx` update the `@instructure/` dependencies to the latest version
+2. In `packages/__docs__/src/Hero/index.tsx` update title of the Upgrade Guide button
+3. In `packages/__docs__/src/CodeSandboxButton/index.tsx` update the `@instructure/` dependencies to the latest version
 
-##### 4. Do a release like it was a minor update
+##### 5. Do a release like it was a minor update
 
 Follow the same process as it's described above. The `npm run bump` command should automatically recognise that there were a breaking commit and it should be a major version change.

docs/contributor-docs/theming/theming-class-based.md

@@ -27,13 +27,6 @@ import generateComponentTheme from './theme'
 
 @withStyle(generateStyle, generateComponentTheme)
 class Button extends React.Component {
-  static propTypes = {
-    // eslint-disable-next-line react/require-default-props
-    makeStyles: PropTypes.func,
-    // eslint-disable-next-line react/require-default-props
-    styles: PropTypes.object
-  }
-
   componentDidMount() {
     this.props.makeStyles()
   }
@@ -213,13 +206,6 @@ type: code
 ---
 // Button/index.js
 class Button extends React.Component {
-  static propTypes = {
-    // eslint-disable-next-line react/require-default-props
-    makeStyles: PropTypes.func,
-    // eslint-disable-next-line react/require-default-props
-    styles: PropTypes.object
-  }
-
   constructor(props) {
     super(props)