How can we lock the version of Polaris Web Components loaded from the CDN?

Hi everyone :waving_hand:

I’ve been experimenting with the new Polaris Web Components, and I noticed that the recommended way to include them is via:

<script src="https://cdn.shopify.com/shopifycloud/polaris.js"></script>

However, it seems that this script always retrieves the latest version available.

As app developers, we often need to ensure our carefully designed UI experiences remain stable and consistent over time. Automatic upgrades could potentially introduce unexpected visual or behavioral changes, which we might prefer to test and integrate manually.

My question is:
Is there currently a way to lock or pin a specific version of Polaris Web Components when loading from the CDN?
For example, something like:

<script src="https://cdn.shopify.com/shopifycloud/polaris/vX.Y.Z/polaris.js"></script>

Or alternatively, a recommended best practice to manage version control for these assets?

We’d like to have control over when to upgrade Polaris, so we can handle updates at our own pace and ensure everything remains stable for merchants using our apps.

1 Like

(post deleted by author)

@HamzaDincer NPM is for the React polaris deprecated library - my post is only relevant for the new Web components.

@muchisx The only way to 100% guarantee a specific version is to serve it yourself.

1 Like

The Polaris Web Components are explicitly versionless for now – you will automatically get bug fixes, style changes, etc. that keeps you in sync with Shopify Admin.

Hi @Anthony_Frehner

Thanks for the reply!

Are there any plans to expose a versioned URLs for the web components?

I understand the Pros you’ve described - however, our Cons are outlined in my post.

3 Likes

I agree. I understand the teams reason for why they want one version but the truth is we are now out of the early release phase and now in the full release, yet the team still makes breaking changes to components.

Either changes need to not be breaking or they need to have a system for rolling updates. Maybe have an unstable, stable and release channel for the components?

2 Likes

Just today I’ve found two cases where updates to web components behind the scene have broken functionality in my app:

This is quite frustrating. If Shopify want to make the argument that the advantages of constantly updated styling and bug fixes outweigh the risks of breakage, they’re going to have to have much better QA on their releases across a range of behaviours and settings. The current state of things is really not acceptable, and it seems really irresponsible to encourage developers to ship functionality built on these components to production.

4 Likes

To be clear, the root cause of some of these issues isn’t the Polaris CDN script, so while I understand that it’s frustrating to deal with, it’s also not accurate to blame the Polaris CDN for these regressions.

I’m asking the team in charge of extensibility for an update on them. Thanks!

1 Like

The problem with version-less is that sync with the Admin is not the same as working , or passing tests, or support burdens.
It’s not like there’s a place inside the admin with ALL possible Polaris part-combinations where developers can point a merchant at to confirm any possible upstream issues; unless were gonna start seeing polaris snafus as incidents in shopifystatus.com :rofl: .

For anyone interested: I’ve launched two unofficial changelog trackers for Polaris and App Bridge to help stay informed about changes. The goal is to provide insight into new updates and make it easier to see whether there’s a correlation between a new issue and a new release of Polaris and/or App Bridge. They also provide a hosted version of every release, allowing you to roll-back to a previous version of Polaris or App Bridge.

6 Likes

@Philo The actual :goat:!

Beat me to it, I was in the drawing board for something like this. Thank you!

1 Like

Love it! Feel free to link or copy/paste the changelog that I post as well; I don’t mind, I just want the info out there :smile: . March 16, 2026 Updates to Admin Polaris Library

It also helps keep us honest in trying to post our changelogs haha.

2 Likes

Hi @Anthony_Frehner

Thanks! I had no idea there was a changelog on here. I’m curious, isn’t there a possibility to make both Polaris and AppBridge public GitHub repo’s? This would make much easier, as you guys don’t have to post manual change logs, and I don’t have to extend these domains next year haha, so we can just look at the github repo commits / releases.

For me it feels like a lot of the important information for app developers / partners is scattered, difficult to find and no option to get updates actively via email for example.

1 Like

Good question; unfortunately, no, not with how things currently work within Shopify.

This is fantastic, thank you! Anyone maintaining a production Shopify app should be subscribed to these.

1 Like

Moving the discussion from my previous post to keep things in one place.


Here are a few thoughts on how we could solve the versioning issue:

  • npm distribution: This is the most professional route. It allows for proper bundling and ships types directly, which would eliminate the need for the separate @shopify/polaris-types package.
  • Versioned CDN URLs: We should at least have the option to pin a version in the URL (e.g., /v1.2.3/polaris.js) if we choose to.
  • Incentives, not force: I understand Shopify wants apps to stay in sync with the Admin UI, but automatic updates aren’t the answer. This could be managed like Admin API versions. The library could simply write its version to the window object, allowing Shopify to monitor which version an app is using via their existing app health/web vitals tracking. They could then notify developers in the Partner Dashboard when an update is required or a version is nearing deprecation.

Ideally, Shopify should provide both. An npm package for production-grade apps and a versioned CDN for quick prototypes or simpler implementations.

6 Likes