TFS 2019 and commitment issues

My JavaScript TFS extensions broke in TFS Azure DevOps 2019. All my complaints about TFS API surface being underdocumented came to their logical conclusion: no docs means no API commitment, no commitment means the team behind the API gets to make breaking changes with no guilt.

Let me count the ways things broke:

Uncategorised extensions

Categories used to be an optional field in the manifest. It's required now.

Registering context menu commands

It used to be that the first argument of VSS.register() had to match the contribution ID. Now it has to match a brand new contribution property from the manifest, registeredObjectId.

jQuery

Used to be that jQuery's $ global object was available to JavaScript extension code from the get-go. Now you have to call VSS.require() for it to become available. In my case, I require VSS/Service, that's apparently sufficient.

CORS

Used to be that jQuery AJAX calls to non-TFS REST services from the extension would have an Origin header for CORS compliance. Not anymore. Tested on Chrome and MSIE.

Page refresh

Used to be that the argument to the custom context menu command implementation would have a view property with a refresh() method. Not anymore. You can refresh the page by calling reload() on the navigation service object, which can be obtained asynchronously via VSS.getService(VSS.ServiceIds.Navigation).

---

Some features didn't break per se:

Custom release summary sections

The release summary screen as we know it is gone, but there's still a release summary UI in the right-hand panel, it opens up once you click on a release box. The custom sections, as provided by extensions, are there and open up once you click them. In other words, they didn't disappear altogether, but they're two clicks away now.

Despite the claims in this document from October 2018, the legacy contributions of type "release summary section" don't need any re-engineering. They work like they used to, modulo the placement.

SOAP notifications

Not JavaScript extension related, but it's a part of my tooling, too. For collection-level notification subscriptions, the SOAP option is quietly gone. The subscription records that existed before the upgrade do show up and are delivered, but for new subscriptions, the SOAP option is no longer available.

There's a REST API for creating subscriptions programmatically, and there are several options for the delivery channel there, SOAP included, so chances are, it's not entirely out.