From the Jira DC 9.2 Preparing for:

As part of already implemented and planned changes, we’ve modified multiple AMD module names, which start with jira-agile/. If you’re using those in your apps, you’ll need to adjust module names to ensure that your applications work correctly.

The updates mainly entail changing kebab-case to PascalCase convention. Global variables are left intact. However, as they are also non-API parts, we don’t recommend using them.

You can read more about the changes and why we decided to proceed with the current approach in Jira DC Front-end API Announcement.

We plan some changes to AMD modules in the upcoming Jira versions.

If there are any important modules that you think should remain unchanged, let us know about your use case and particular module as a comment under this ticket.

We’ll take it into consideration while working on further changes.

From Preparing for Jira 9.6 (as a heads-up for Jira 9.7):

As announced in Preparing for Jira 9.2, we’re making changes to how we bundle and serve client-side code in Jira Software, aiming to modernize the codebase and speed up page loading time in the app.

We plan to release these changes in Jira 9.7 and now finalizing all the received feedback. Please share with us any dependencies that your app has in Jira Software views (Board, Backlog, Reports, Configure board, and View all boards), especially on AMD modules or global variables. 

We’ll consider your front-end dependencies on Jira’s code to make sure that after the upgrade these changes won’t affect your apps’ work or there’ll be a clear migration path at least.

To sum up:

• many AMD module names, which start with jira-agile/, will become unavailable from the AMD modules registry point of view (e.g. `window.require` call), unless we explicitly expose them, hence the ask to share those used ones with us,
• global variable names are kept intact, however:
• as we'll be pushing forward better isolation and inclusion of JS/CSS assets on Software pages, please pay attention to explicitly defining dependencies on your front-end code (per the Jira DC Front-end API), as previous transitive dependencies may not be present.
  For example, using a JS module from Board config on Reports page, or using a Backlog module on Reports page, or using Reports module on Board page, etc.
  In such cases, it's worth considering whether we actually need that module or could be replaced with more local equivalent. If the module is needed indeed, depending on the use case, let's consider: a) lazy-loading the web-resource context/key b) waiting for the navigation to occur before executing that JS c) adding the explicit dependency on the suitable web-resource key (beware that this can increase the page weight for all users on a given page).