Remove accessory capability/slot from TextArea component

[prakashraman]

Resolves https://github.com/shop/issues-retail/issues/21304

Background

This PR refines the TypeScript definitions for the TextArea component in the Point of Sale UI extensions.

Solution

This change streamlines the type definitions by:

• Removing the accessory prop from the TextAreaJSXProps interface

These changes make the type definitions more maintainable while preserving type safety.

🎩

• Verified that existing components using TextArea still compile correctly
• Confirmed that the type definitions work as expected in the Point of Sale surface

Checklist

• I have 🎩'd these changes
• I have updated relevant documentation

[prakashraman]

• Remove accessory capability/slot from TextArea component #3603 👈 (View in Graphite)
• 2026-01-rc

This stack of pull requests is managed by Graphite. Learn more about stacking.

[prakashraman]

hmmm, I might need a second pair of eyes 👀 , to see if I generated the type docs properly.

I ran

BUILD_VERSION=2026-01 pnpm build-extension-components

Which generated the docs, however, when I

BUILD_VERSION=2026-01 pnpm build-extension-components:publish

over to the ui-extensions repo, I see quite more differences than I was expecting. As @BrittaEvansFenton suspected, could we have others making changes directly on this repo? Or are we supposed to manage these docs differently?

[prakashraman]

@BrittaEvansFenton thanks for walking me through my question above.

I've created a sub-issue for the docs, and have mentioned it at the top of the PR description.

Do review when you can.

[BrittaEvansFenton]

Is this not a major change?

[prakashraman]

hmmmm, I see what you mean. It is a breaking change in the sense that a behavior is no longer supported, but it does not break the build itself.

That being said, when I look at recent version history https://www.npmjs.com/package/@shopify/ui-extensions?activeTab=versions

It does not, anymore, follow a strict semver versioning right? It is now yyyy.mm.<patch>

I'm split on the change-level. I'll go with your advice - what shall we do? Shall we go with major?

And for my understanding, what would that version look like? (2026.02.01) ?

[BrittaEvansFenton]

hmmmm

[BrittaEvansFenton]

wouldn't 2025 -> 2026 account for the major in this case anyways?

[prakashraman]

Merge activity

• Dec 10, 4:42 PM UTC: A user started a stack merge that includes this pull request via Graphite.
• Dec 10, 4:43 PM UTC: Graphite rebased this pull request as part of a merge.
• Dec 10, 4:44 PM UTC: @prakashraman merged this pull request with Graphite.