Merge remote-tracking branch 'origin/main' into benelan/7889-clear-ma…

…x-constraint

* origin/main: (37 commits)
  build(deps): update dependency @stencil/core to v4.18.2 (#9266)
  refactor(stepper-item): drop unnecessary transitions (#9327)
  docs(contributing): add commit message formatting details (#9389)
  docs: update component READMEs (#9328)
  build: update browserslist db (#9263)
  chore: release next
  fix(tree): allow single select only and add indicator (#9405)
  chore: release next
  feat(split-button): Make dividers consistent (#9402)
  chore: release next
  feat(stepper, stepper-item): add separate change events to stepper and items (deprecates `calciteStepperItemChange` on the parent) (#9351)
  chore(tree): fix multiple selection-mode values set in slotted dropdown-groups (#9378)
  fix(dropdown-group): title scale with dropdown scale (#9360)
  chore: release next
  fix(tree): allow deselection in single selectionMode (#9363)
  chore: Update placeholder images in stories and demos (#9395)
  chore: use local placeholder image in html files (#9392)
  chore: release next
  chore: release hotfix (#9382)
  fix(combobox): fix error that occurs when a click is emitted when the component is appended to the DOM (#9380)
  ...

.github/ISSUE_TEMPLATE/accessibility.yml

@@ -91,11 +91,10 @@ body:
       multiple: false
       description: What is the impact to you, your team, or organization? Use discretion and only select "need" or "emergency" priorities for high user impact and quality issues. For instance, would someone notice, in a bad way, if this issue were present in the release?
       options:
-        - p4 - not time sensitive
-        - p3 - want for upcoming milestone
-        - p2 - want for current milestone
-        - p1 - need for current milestone
-        - p0 - emergency
+        - impact - p3 - not time sensitive
+        - impact - p2 - want for an upcoming milestone
+        - impact - p1 - need for current milestone
+        - impact - p0 - emergency
   - type: checkboxes
     id: packages
     attributes:

.github/ISSUE_TEMPLATE/bug.yml

@@ -78,11 +78,10 @@ body:
       multiple: false
       description: What is the impact to you, your team, or organization? Use discretion and only select "need" or "emergency" priorities for high user impact and quality issues. For instance, would someone notice, in a bad way, if this issue were present in the release?
       options:
-        - p4 - not time sensitive
-        - p3 - want for upcoming milestone
-        - p2 - want for current milestone
-        - p1 - need for current milestone
-        - p0 - emergency
+        - impact - p3 - not time sensitive
+        - impact - p2 - want for an upcoming milestone
+        - impact - p1 - need for current milestone
+        - impact - p0 - emergency
   - type: textarea
     id: impact
     attributes:

.github/ISSUE_TEMPLATE/enhancement.yml

@@ -54,10 +54,10 @@ body:
       multiple: false
       description: What is the impact of the enhancement to you, your team, or organization? Use discretion and only select the "need" priority for high user impact and quality issues in the component(s).
       options:
-        - p4 - not time sensitive
-        - p3 - want for upcoming milestone
-        - p2 - want for current milestone
-        - p1 - need for current milestone
+        - impact - p3 - not time sensitive
+        - impact - p2 - want for an upcoming milestone
+        - impact - p1 - need for current milestone
+        - impact - p0 - emergency
   - type: checkboxes
     id: packages
     attributes:

.github/ISSUE_TEMPLATE/new-component.yml

@@ -51,10 +51,10 @@ body:
       multiple: false
       description: How important is the new component request to you, your team, or organization? Use discretion and only select the "need" priority for high user impact.
       options:
-        - p4 - not time sensitive
-        - p3 - want for upcoming milestone
-        - p2 - want for current milestone
-        - p1 - need for current milestone
+        - impact - p3 - not time sensitive
+        - impact - p2 - want for an upcoming milestone
+        - impact - p1 - need for current milestone
+        - impact - p0 - emergency
   - type: dropdown
     id: esri-team
     validations:

.github/ISSUE_TEMPLATE/tooling.yml

@@ -7,6 +7,18 @@ body:
       value: |
         - Please [check for existing issues](https://github.com/Esri/calcite-design-system/issues) to avoid duplicates. If someone has already opened an issue for what you are experiencing, please add a 👍 reaction to the existing issue instead of creating a new one.
         - For support, please check the [community forum](https://developers.arcgis.com/calcite-design-system/community/).
+  - type: dropdown
+    id: priority-impact
+    validations:
+      required: true
+    attributes:
+      label: Priority impact
+      multiple: false
+      description: What is the impact of the requested improvement? If the need is blocking release, the priority may be high, where a new improvement may have a low or medium priority.
+      options:
+        - p - low
+        - p - medium
+        - p - high
   - type: textarea
     id: summary
     attributes:

.release-please-manifest.json

@@ -1,7 +1,7 @@
 {
-  "packages/calcite-components": "2.8.1",
-  "packages/calcite-components-react": "2.8.1",
+  "packages/calcite-components": "2.8.3",
+  "packages/calcite-components-react": "2.8.3",
   "packages/calcite-design-tokens": "2.2.0",
   "packages/eslint-plugin-calcite-components": "1.2.0",
-  "packages/calcite-components-angular/projects/component-library": "2.8.1"
+  "packages/calcite-components-angular/projects/component-library": "2.8.3"
 }

CONTRIBUTING.md

@@ -214,30 +214,107 @@ johndoe/feature/add-something-to-modal
 
 ## Commit message format
 
-This project follows [conventional commits](https://www.conventionalcommits.org/en/v1.0.0/), which are used to generate the changelog. Be sure to provide clear and sufficient information in commit messages. This is important because the commit messages are used to automatically update the changelog.
+Calcite follows [conventional commits](https://www.conventionalcommits.org/en/v1.0.0/), which are used to generate the changelog. Be sure to provide clear and sufficient information in commit messages. This is important because the commit messages are used to generate the changelog automatically.
+
+Contributions should adhere to the `<type>(<scope>): <descriptive summary>` format and include the following:
+
+- [Convention type](#convention-type)
+- [Scope of change](#scope-of-change), *optional*
+- [Descriptive commit subject](#descriptive-commit-subject)
+
+Check out the [contribution example](#contribution-example) for a formatted example, and explore [breaking change formatting](#breaking-changes) for consideration during Calcite's breaking change releases.
+
+### Convention type
+
+Contributions must adhere to **one** of the following conventions:
+
+- **`chore`**: Adds a new build process, or auxiliary tool and libraries (e.g., documentation generation) 🤖
+- **`docs`**: Documentation only changes 📚
+- **`feat`**: Adds a new feature, or functionality ✨
+- **`fix`**: Fixes a bug 🐛
+- **`perf`**: A change improving performance 🚀
+- **`refactor`**: A change that neither fixes a bug or adds a feature 🔁
+- **`revert`**: Reverts a previous commit ↪️
+- **`test`**: Improves test coverage in updating a test or adding a new, or missing test 🧪
+
+### Scope of change
+
+*Optional*. Most contributions will include a scope, such as a component, multiple components, test(s), or utilities. For example:
+
+- `text-area`
+- `dropdown, dropdown-group, dropdown-item`
+- `common`
+
+Not all commits will contain a scope, however it is recommended to include scope when possible.
+
+### Descriptive commit subject
+
+The subject should contain a concise description of the proposed change, where contributors will:
+
+- **Be succinct, yet informative** to ensure the change's purpose is conveyed once added to the changelog
+- Describe the commit's purpose, not a related issue or how the change was mitigated
+- Use present tense, such as "update" instead of "updated" or "updates"
+- Not capitalize the first letter
+- Not insert a period `.` at the end
+
+### Contribution example
 
 For instance, if providing a bug fix to the Text Area component, which includes additional support to assistive technologies, you could use the following conventional commit:
 
-> fix(text-area): provide additional support to assistive technologies
+```text
+fix(text-area): provide additional support to assistive technologies
+```
 
-[Stencil's contributing document](https://github.com/ionic-team/stencil/blob/main/CONTRIBUTING.md#commit-message-format) explains this in great detail. Please refer to the above link for more conventional commit details and examples, and visit [Calcite's recent commits](https://github.com/Esri/calcite-design-system/commits/main) to refer to additional examples.
+A more in-depth description can be added to the PR's body summary. For example:
+
+```text
+Related Issue: <Issue number>
+
+### Summary
+Provide additional context for assistive technology users when the component's character limit exceeds the `maxLength` property. Assistive technology users recieve an error message as soon as the character limit is exceeded.
+```
+
+For more information, explore [Stencil's contributing document](https://github.com/ionic-team/stencil/blob/main/CONTRIBUTING.md#commit-message-format). Please refer to the above link for more conventional commit details and examples, and visit [Calcite's recent commits](https://github.com/Esri/calcite-design-system/commits/main) to refer to additional examples.
 
 ## Breaking changes
 
 Calcite Core team members should be consulted prior to submitting breaking change pull requests. For stability and consistency, breaking change sprints are coordinated and communicated well in advance.
 
-When breaking changes are supported in a current sprint, commit messages for breaking changes should use both the header (`!`) and body (`BREAKING CHANGE:`) syntax:
+When breaking changes are supported in a current milestone, commit messages for breaking changes should use both the header (`!`) and body (`BREAKING CHANGE:`) syntax.
+
+The PR's details should be comprehensive, and when possible, include the following:
+
+- What the proposed breaking change includes
+- Why the breaking change is proposed
+- An example to support users migrating from the previous major version (e.g., `1.x` to `2.x`)
+
+For PR examples, refer to previous changelog entries from the `2.0` major releases for [calcite-components](https://github.com/Esri/calcite-design-system/blob/main/packages/calcite-components/CHANGELOG.md#200-2023-12-02) and [calcite-design-tokens](https://github.com/Esri/calcite-design-system/blob/main/packages/calcite-design-tokens/CHANGELOG.md#200-2023-12-02). Also explore the breaking change structure below:
 
 ```text
-<type>!: <descriptive summary>
+<type>(<scope>)!: <descriptive summary>
 
 <optional info>
 
-BREAKING CHANGE: <details about the change and migration options (this can span multiple lines)>
+BREAKING CHANGE: <What the breaking change includes, why it is proposed, and migration support for users>
 ```
 
 When adding a `BREAKING CHANGE:` note to the summary block right before confirming a squash merge, remove all the info except the `BREAKING CHANGE:` note itself, or else everything ends up being added to the changelog.
 
+### Breaking change contribution example
+
+For instance, if adding a refactored breaking change to the Modal component, you could use the following conventional commit:
+
+```text
+refactor(modal)!: rename `width` property to `widthScale`
+```
+
+And a more in-depth, but succinct description for the PR's body summary could include:
+
+```text
+Related Issue: <Issue number>
+BREAKING CHANGE: For consistency, renames `width` property to `widthScale`.
+```
+
 See the [conventional commits doc](https://www.conventionalcommits.org/en/v1.0.0/) for more helpful information.
 
 ## Pull requests