AUI 8 discussion: consumption and distribution of AUI

Hey all!

I’m interested in making it easier to build the frontend of your apps when using AUI. Since it’s hard to guess what people need, having an open discussion about it seems a much nicer approach :wink:

The AUI team recently released AUI 8.0, which changed the shape of its various distributions. If you read the upgrade guide, you may have noticed the following disclaimer:

As mentioned in the packaging section, a number of changes were made to how AUI is distributed. These affect the Node distribution in a significant way.

The “prototyping” bundle of AUI is not intended to be used in production systems.
Add a comment to AUI-4829 noting the components and patterns you use. This will inform future efforts to build better bundles that contain only what you need.

AUI can be consumed three or four discrete ways, which makes shipping it a complicated balancing act between developer ergonomics and runtime costs.

  • One method is to use URL links from a CDN like This is what the AUI docs do.
  • Yet another (and most common within Atlassian and its Server products) is to use the Atlassian Plugin artifact and import via web-resource definitions.
  • Webpack is a more recent consumption method, and a subcategory of bundling with solutions alongside Rollup / Parcel / Closure Compiler.

I’d like to strike a decent balance and compromise between these various methods of consumption.

The bundling use-case is the most challenging to support, since it implies we need to output “almost source” to developers who will then use it as input to their own builds. The challenge is to strike a balance between making zero assumptions about downstream build environments, internal tooling/build pipelines to output the appropriate “almost source”, and somehow documenting it in a way that makes sense.

The need for an SVG loader is a good example of this challenge. At present, some parts of AUI use SVG assets, which the aui-prototyping.js file references as external relative URLs. If you point Webpack at that file, it will bail when it can’t understand SVG. So, you need to add svg-loader to your webpack build. But should you have to do that? Then, should we document how to do this in the docs? Adding an example consumption for every possible build tool seems like a losing battle – Rollup, Parcel, and Closure Compiler all have different ideas on how to do this kind of thing. So, to avoid this, maybe AUI would need to inline every external asset it uses. But, if it did that, that would include some Atlassian-specific assets like the Atlassian brand logos, which have a restricted license, which you probably don’t want…

In short, there’s not going to be a one-size-fits-all solution for distributing AUI. What I hope to arrive at is at least one “good enough” solution for each discrete use-case.

With that in mind, I’ve got a few questions that’d be great to get some data for:

Are you building Cloud or Server apps using AUI?

  • Cloud
  • Server
  • Something else (leave a comment)

0 voters

How are you consuming AUI?

  • A CDN like or
  • The Atlassian Plugin
  • Distribution files from the NPM package
  • Distribution files from the “flat-pack”
  • Raw source from the NPM package
  • Raw source from Bitbucket
  • Something else (leave a comment)

0 voters

Are you using a bundler or compiler for your UI code?

  • No bundler
  • Webpack
  • Rollup
  • Parcel
  • Something else (leave a comment)

0 voters

How do you import and use JavaScript code?

  • AMD modules
  • ES6 imports
  • Global variables
  • Something else (leave a comment)

0 voters

I’d love to hear more about what you need from AUI. Show me the kind of code you want to be writing, then let’s look at making it work :slight_smile:

1 Like

Thanks goes to @scottohara for providing some context around his attempted usage of AUI 8 in a Connect app.

Cheers @lmyslinski for the feedback on the AUI 8 flatpack. It turns out our docs don’t actually mention that jQuery needs to be on the page before AUI, so I’ve raised AUI-4960 to ensure we fix that.