Dependency Updates for December 2024 (#2485)

# Pull Request

## 🤨 Rationale

Updates dependencies manually to address build issues revealed by #2482
#2481 #2480.
Found that just updating dependencies by rebuilding the lock fails the
build which means the [repo is in a bad
state](#1479 (comment))
and that should be addressed quickly.

## 👩‍💻 Implementation

- Update major deps and rebuild lock
- Found that the now [deprecated tiptap link
validate](https://tiptap.dev/docs/editor/extensions/marks/link#validate-deprecated)
function is expected to still function with [backwards
compat](ueberdosis/tiptap#5812) however there
seems to be a regression as it [fails our build by allowing autolinking
of unexpected
protocols](https://github.com/ni/nimble/actions/runs/12110590706/job/33761233944#step:17:613).
- Switched from tiptap link validate to
[shouldAutoLink](https://tiptap.dev/docs/editor/extensions/marks/link#shouldautolink)
as described by docs. That seems to not fail the build.
- Pushed the min semver range version up for all the tiptap /
prosemirror packages as otherwise it seems to[ fail build when type
checking libraries](ueberdosis/tiptap#5867).
   
**NOTE**: It seems to be transitive dependency type issues that will
fail builds, I think it's possible that minimal upgrades done by
renovate may hit issues in app updates. If an app adopting latest these
changes fails to build it may need to rebuild the lock files in a clean
workspace to align transitive deps on latest versions and avoid library
type check issues.
- Updates to [prettier
3.4](https://prettier.io/blog/2024/11/26/3.4.0.html) resulting in lots
of changes.

## 🧪 Testing

Rely on CI.

## ✅ Checklist

- [x] I have updated the project documentation to reflect my changes or
determined no changes are needed.

change/@ni-nimble-components-2928e7be-919f-4a54-8ad3-a37ba46eb5fe.json

@@ -0,0 +1,7 @@
+{
+  "type": "patch",
+  "comment": "Update rich text dependencies",
+  "packageName": "@ni/nimble-components",
+  "email": "[email protected]",
+  "dependentChangeType": "patch"
+}

change/@ni-spright-components-ec147704-81e1-455a-8ef3-16621b69ba3b.json

@@ -0,0 +1,7 @@
+{
+  "type": "patch",
+  "comment": "Updates from lint changes",
+  "packageName": "@ni/spright-components",
+  "email": "[email protected]",
+  "dependentChangeType": "patch"
+}

packages/nimble-components/CONTRIBUTING.md

@@ -81,15 +81,15 @@ Before building a new component, 3 specification documents need to be created:
 
 If a component is not ready for general use, it should be marked as "incubating" to indicate that status to clients. A component could be in this state if any of the following are true:
 
--   It is still in development.
--   It is missing important features like interaction design, visual design, or accessibility.
+- It is still in development.
+- It is missing important features like interaction design, visual design, or accessibility.
 
 Incubating contributions may compromise on the above capabilities but they still must abide by other repository requirements. For example:
 
--   Start development with a spec describing the high level plan and what's in or out of scope
--   Coding conventions (element naming, linting, code quality)
--   Unit and Chromatic test coverage
--   Storybook documentation
+- Start development with a spec describing the high level plan and what's in or out of scope
+- Coding conventions (element naming, linting, code quality)
+- Unit and Chromatic test coverage
+- Storybook documentation
 
 To mark a component as incubating:
 
@@ -187,17 +187,17 @@ Component CSS should follow the patterns described in [CSS Guidelines](/packages
 
 It is common in web development to represent variations of control states using css classes. While it is possible to apply custom styles to web components based on user-added CSS classes, i.e. `:host(.my-class)`, it is not allowed in nimble for the following reasons:
 
--   The `class` attribute is a user-configured attribute. For native HTML elements it would be surprising if setting a class, i.e. `<div class="my-class">`, caused the element to have a new style that the user did not define in their stylesheet. However, other attributes are expected to have element defined behavior, i.e. `<div hidden>`.
--   Classes set in the `class` attribute are not as well-typed across frameworks. Users have to contort a bit to use exported enums for CSS class strings while attributes and attribute values are well-typed in wrappers.
--   Binding to updates in the `class` attribute is more difficult / not an expected pattern. This makes it difficult to forward configured properties to inner elements. Alternatively, binding to attributes and forwarding bound attribute values in templates is a well supported pattern.
+- The `class` attribute is a user-configured attribute. For native HTML elements it would be surprising if setting a class, i.e. `<div class="my-class">`, caused the element to have a new style that the user did not define in their stylesheet. However, other attributes are expected to have element defined behavior, i.e. `<div hidden>`.
+- Classes set in the `class` attribute are not as well-typed across frameworks. Users have to contort a bit to use exported enums for CSS class strings while attributes and attribute values are well-typed in wrappers.
+- Binding to updates in the `class` attribute is more difficult / not an expected pattern. This makes it difficult to forward configured properties to inner elements. Alternatively, binding to attributes and forwarding bound attribute values in templates is a well supported pattern.
 
 ##### Attribute naming convention
 
--   Do not use attribute names that conflict with native attribute names:
-    -   Avoid any names in the [MDN HTML attribute reference list](https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes#attribute_list) (unless the attribute is trying to match that behavior exactly).
-    -   Do a best effort search in relevant working groups for new attributes that may be coming to avoid, i.e. https://github.com/openui and https://github.com/whatwg.
-    -   Avoid any names that are [reserved words](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Lexical_grammar#reserved_words) in JavaScript.
--   Use lower-kebab-case for attributes and enum values that are part of a component's public API.
+- Do not use attribute names that conflict with native attribute names:
+    - Avoid any names in the [MDN HTML attribute reference list](https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes#attribute_list) (unless the attribute is trying to match that behavior exactly).
+    - Do a best effort search in relevant working groups for new attributes that may be coming to avoid, i.e. https://github.com/openui and https://github.com/whatwg.
+    - Avoid any names that are [reserved words](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Lexical_grammar#reserved_words) in JavaScript.
+- Use lower-kebab-case for attributes and enum values that are part of a component's public API.
 
     ```ts
         @attr({ attribute: 'error-text' })
@@ -206,19 +206,19 @@ It is common in web development to represent variations of control states using
 
 ##### Attribute common name patterns
 
--   For attributes that control the visibility of a part, use either the boolean attribute `<part>-visible` or `<part>-hidden`, i.e. `icon-visible` or `icon-hidden`.
+- For attributes that control the visibility of a part, use either the boolean attribute `<part>-visible` or `<part>-hidden`, i.e. `icon-visible` or `icon-hidden`.
 
     The default configuration should be the most common configuration and the boolean attribute should be added for the less common alternate configuration that differs from the default. An element should NOT implement both `-visible` and `-hidden` attributes for a given `<part>`, only one or the other.
 
--   Use the `appearance` attribute to represent mutually exclusive visual modes of a component that represent large style changes. Likely implemented with an attribute behavior.
+- Use the `appearance` attribute to represent mutually exclusive visual modes of a component that represent large style changes. Likely implemented with an attribute behavior.
 
     An `appearance-variant` attribute may also be used to represent smaller mutually exclusive variations of an appearance. Likely implemented with CSS attribute selectors.
 
 ##### Attribute common value patterns
 
--   When applicable, the default value for an attribute that is allowed to be unconfigured should be first in the enum object, have a descriptive enum name, such as `default`, `none`, etc, based on the context, and be the enum value `undefined`.
--   Boolean attributes must always default to `false`. Otherwise, the configuration in HTML becomes meaningless, as both `<element></element>` and `<element bool-attr></element>` result in `bool-attr` being set to `true`.
--   States representing the following ideas should use those names: `success`, `error`, `warning`, `information`.
+- When applicable, the default value for an attribute that is allowed to be unconfigured should be first in the enum object, have a descriptive enum name, such as `default`, `none`, etc, based on the context, and be the enum value `undefined`.
+- Boolean attributes must always default to `false`. Otherwise, the configuration in HTML becomes meaningless, as both `<element></element>` and `<element bool-attr></element>` result in `bool-attr` being set to `true`.
+- States representing the following ideas should use those names: `success`, `error`, `warning`, `information`.
 
     Avoid shorthands, i.e. `warn`, `info` and avoid alternatives, i.e. `pass`, `fail`, `invalid`.
 
@@ -270,8 +270,8 @@ Components can also consider exposing an API that checks the validity of the com
 
 It is acceptable to throw exceptions in production code in other situations. For example:
 
--   when a case gets hit that should be impossible, like an invalid enum value.
--   from a component method when it shouldn't be called in the component's current state, like `show()` on a dialog that is already open.
+- when a case gets hit that should be impossible, like an invalid enum value.
+- from a component method when it shouldn't be called in the component's current state, like `show()` on a dialog that is already open.
 
 #### Comments
 
@@ -281,8 +281,8 @@ At a minimum all classes should have a block comment and ultimately all parts of
 
 Accessibility is a requirement for all new components. For the Nimble design system, this means
 
--   Focus states are defined for every element and work on all browsers.
--   Colors have sufficient contrast across all themes.
+- Focus states are defined for every element and work on all browsers.
+- Colors have sufficient contrast across all themes.
 
 This is a collaborative effort between development and design. Designers will do their due diligence to make sure that designs promote accessiblity, and developers must ensure that each design is implemented and tested across browsers and themes.
 
@@ -359,11 +359,11 @@ Consider whether or not the `delegatesFocus` shadow DOM option should be set to
 
 Some guidelines to follow when deciding whether or not to set `delegatesFocus`:
 
--   For a component built on top of a fast-foundation component, check the fast-foundation component's README.md to see if the component was built with the expectation that focus will be delegated.
--   Non-interactive elements should keep `delegatesFocus` with the default `false` value.
--   Interactive controls that contain no focusable components in the shadow root should keep `delegatesFocus` with the default `false` value.
--   Interactive controls that contain focusable components in the shadow root should set `delegatesFocus` to `true`.
--   Refer to [MDN](https://developer.mozilla.org/en-US/docs/Web/API/Element/attachShadow#parameters) or [this table](https://github.com/TakayoshiKochi/tabindex-focus-navigation-explainer/blob/master/TabindexFocusNavigationExplainer.md#proposed-solution) for more information.
+- For a component built on top of a fast-foundation component, check the fast-foundation component's README.md to see if the component was built with the expectation that focus will be delegated.
+- Non-interactive elements should keep `delegatesFocus` with the default `false` value.
+- Interactive controls that contain no focusable components in the shadow root should keep `delegatesFocus` with the default `false` value.
+- Interactive controls that contain focusable components in the shadow root should set `delegatesFocus` to `true`.
+- Refer to [MDN](https://developer.mozilla.org/en-US/docs/Web/API/Element/attachShadow#parameters) or [this table](https://github.com/TakayoshiKochi/tabindex-focus-navigation-explainer/blob/master/TabindexFocusNavigationExplainer.md#proposed-solution) for more information.
 
 If it is determined that the component should delegate focus, it can be configured as shown below:
 
@@ -423,26 +423,26 @@ The following commands can be run from the `nimble` directory:
 
 ### Development commands
 
--   `npm run tdd:watch -w @ni/nimble-components`: Starts a process for building the components and running the test suite on file changes.
+- `npm run tdd:watch -w @ni/nimble-components`: Starts a process for building the components and running the test suite on file changes.
 
     This command runs headlessly. See [Debugging commands](#debugging-commands) if you need to see the browser or set breakpoints while running.
 
--   `npm run tdd -w @ni/nimble-components`: Similar to the corresponding `tdd:watch` command but only runs once. Useful for infrastructure changes which do not trigger the watch command.
+- `npm run tdd -w @ni/nimble-components`: Similar to the corresponding `tdd:watch` command but only runs once. Useful for infrastructure changes which do not trigger the watch command.
 
 ### Debugging commands
 
--   `npm run test-chrome:debugger -w @ni/nimble-components`: When run opens a Chrome window that can be used for interactive debugging. Using dev tools set breakpoints in tests and refresh the page, etc.
+- `npm run test-chrome:debugger -w @ni/nimble-components`: When run opens a Chrome window that can be used for interactive debugging. Using dev tools set breakpoints in tests and refresh the page, etc.
 
     You can also take the page url and open it in a different browser to test interactively.
 
--   `npm run test-webkit:debugger -w @ni/nimble-components`: Similar to `test-chrome:debugger` but for WebKit. Can be run on Windows.
+- `npm run test-webkit:debugger -w @ni/nimble-components`: Similar to `test-chrome:debugger` but for WebKit. Can be run on Windows.
 
 ### Test utilities
 
 Test utilities located in [`/src/testing`](/packages/nimble-components/src/testing) may be used for testing:
 
--   performed inside the `@ni/nimble-components` package or
--   by other packages in the monorepo or users consuming the built package
+- performed inside the `@ni/nimble-components` package or
+- by other packages in the monorepo or users consuming the built package
 
 Test utilties located in [`/src/utilities/tests`](/packages/nimble-components/src/utilities/tests) are just for tests in the `@ni/nimble-components` package and are not shared externally.
 
@@ -471,22 +471,22 @@ Most user-visible strings displayed by Nimble components are provided by the cli
 
 The current label providers:
 
--   `nimble-label-provider-core`: Used for labels for all components without a dedicated label provider
--   `nimble-label-provider-rich-text`: Used for labels for the rich text components
--   `nimble-label-provider-table`: Used for labels for the table (and table sub-components / column types)
+- `nimble-label-provider-core`: Used for labels for all components without a dedicated label provider
+- `nimble-label-provider-rich-text`: Used for labels for the rich text components
+- `nimble-label-provider-table`: Used for labels for the table (and table sub-components / column types)
 
 The expected format for label token names is:
 
--   element/type(s) to which the token applies, e.g. `number-field` or `table`
-    -   This may not be an exact element name, if this label applies to multiple elements or will be used in multiple contexts
--   component part/category (optional), e.g. `column-header`
--   specific functionality or sub-part, e.g. `decrement`
--   the suffix `label` (will be omitted from the label-provider properties/attributes)
+- element/type(s) to which the token applies, e.g. `number-field` or `table`
+    - This may not be an exact element name, if this label applies to multiple elements or will be used in multiple contexts
+- component part/category (optional), e.g. `column-header`
+- specific functionality or sub-part, e.g. `decrement`
+- the suffix `label` (will be omitted from the label-provider properties/attributes)
 
 Components using localized labels should document them in Storybook. To add a "Localizable Labels" section:
 
--   Their story `Args` should extend `LabelUserArgs`
--   Call `addLabelUseMetadata()` and pass their declared metadata object, the applicable label provider tag, and the label tokens that they're using
+- Their story `Args` should extend `LabelUserArgs`
+- Call `addLabelUseMetadata()` and pass their declared metadata object, the applicable label provider tag, and the label tokens that they're using
 
 ## Component naming
 

packages/nimble-components/README.md

@@ -110,13 +110,13 @@ Most user-visible strings displayed by Nimble components are provided by the cli
 
 The current label providers:
 
--   `nimble-label-provider-core`: Used for labels for all components without a dedicated label provider
--   `nimble-label-provider-rich-text`: Used for labels for the rich text components
--   `nimble-label-provider-table`: Used for labels for the table (and table sub-components / column types)
+- `nimble-label-provider-core`: Used for labels for all components without a dedicated label provider
+- `nimble-label-provider-rich-text`: Used for labels for the rich text components
+- `nimble-label-provider-table`: Used for labels for the table (and table sub-components / column types)
 
 If a client is localized, it should:
 
--   Add the `label-provider` element(s) as children of their root theme provider:
+- Add the `label-provider` element(s) as children of their root theme provider:
     ```html
     <body>
         <nimble-theme-provider theme="light">
@@ -127,14 +127,14 @@ If a client is localized, it should:
         </nimble-theme-provider>
     </body>
     ```
--   For each label token on the label provider API, localize the English string, and set the corresponding HTML attribute or JS property on the label provider to the localized values. A list of all label tokens for each label provider (and their corresponding attribute/property names and English strings) can be found in the [Tokens/Label Providers section of Storybook](http://nimble.ni.dev/storybook/?path=/docs/tokens-label-providers--docs).
+- For each label token on the label provider API, localize the English string, and set the corresponding HTML attribute or JS property on the label provider to the localized values. A list of all label tokens for each label provider (and their corresponding attribute/property names and English strings) can be found in the [Tokens/Label Providers section of Storybook](http://nimble.ni.dev/storybook/?path=/docs/tokens-label-providers--docs).
 
 ## Content Security Policy
 
 When using Nimble in an environment with a [Content Security Policy](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy) enabled, the following are known required settings beyond "common" settings (such as the [OWASP Basic non-Strict CSP Policy](https://cheatsheetseries.owasp.org/cheatsheets/Content_Security_Policy_Cheat_Sheet.html#basic-non-strict-csp-policy)) for using Nimble:
 
--   `style-src 'unsafe-inline'` is [needed to support style patterns in the FAST library](https://github.com/microsoft/fast/issues/4510) leveraged by Nimble.
--   `worker-src blob:` is needed to support controls that leverage Web Workers (for example the Wafer Map).
+- `style-src 'unsafe-inline'` is [needed to support style patterns in the FAST library](https://github.com/microsoft/fast/issues/4510) leveraged by Nimble.
+- `worker-src blob:` is needed to support controls that leverage Web Workers (for example the Wafer Map).
 
 ## Accessibility
 

packages/nimble-components/build/generate-icons/README.md

@@ -2,8 +2,8 @@
 
 ## Behavior
 
--   Depends on the build output of `nimble-tokens` to generate icon components.
--   Generates an icon component file for each icon, and an all-icons.ts file which exports all icon components.
+- Depends on the build output of `nimble-tokens` to generate icon components.
+- Generates an icon component file for each icon, and an all-icons.ts file which exports all icon components.
 
 ## How to run
 

packages/nimble-components/build/generate-scss/README.md

@@ -2,9 +2,9 @@
 
 ## Behavior
 
--   Depends on the build output of the `npm run build-components` command to generate design token names.
--   Generates SCSS files in the nimble component dist with the design token names formatted as SCSS properties.
--   Generates an SCSS file for fonts that imports from Nimble Tokens.
+- Depends on the build output of the `npm run build-components` command to generate design token names.
+- Generates SCSS files in the nimble component dist with the design token names formatted as SCSS properties.
+- Generates an SCSS file for fonts that imports from Nimble Tokens.
 
 ## How to run