Polaris Web Components are a DX nightmare for non-react devs

Shopify is promoting the new Polaris Web Components as “technology-agnostic,” but the development experience for anyone outside the React ecosystem is currently a nightmare. At runtime, they work; at dev-time, they are nearly unusable in a professional Vue/TypeScript workflow.

The Problem: Zero Tooling support in Vue SFCs

The @shopify/polaris-types package defines component metadata exclusively within the JSX.IntrinsicElements namespace. This is a React-centric pattern that Vue’s language server (Volar/VTSLS) simply does not consume.

When using s-* components in a Vue SFC, we get:

  • No Autocomplete: Typing <s- suggests nothing in the template.

  • No Prop Discovery: You have to keep the docs open to know which attributes exist for s-button or s-text-field.

  • Manual Shimming: We have to manually hack Polaris interfaces into Vue’s GlobalComponents just to clear IDE errors and get basic productivity.

The Solution: We need a Custom Elements Manifest (CEM)

If Polaris is truly framework-agnostic, it should not rely on a JSX-based type distribution. The industry standard for this is a Custom Elements Manifest (CEM).

Providing a custom-elements.json would allow:

  1. Universal IDE Support: VS Code and WebStorm could provide native autocomplete in .vue, .html, and other template formats via standard “Custom Data” features.

  2. Automatic Type Generation: Framework-specific types (for Vue, Svelte, etc.) could be generated automatically from the manifest instead of being hand-coded for React.


Are there actual plans to release a Custom Elements Manifest or a version of @shopify/polaris-types that follows W3C standards for metadata instead of relying on the JSX namespace?

4 Likes

Yeah we’ve talked a bit about publishing this! I’ll see what the latest discussion on it is.

1 Like