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:
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.
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.
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?
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.
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!
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 .
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.
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.
.
!
.