config: tales of jQuery and the early days of modules

In the distant past, long before React, ES Modules, fancy bundlers, or
even bower, the web was a very different place. Some might say, it was,
simpler.

Back in those days, to include a dependency in your project you had
primarily had two options:

- Download the required files and place them into a vendor directory.
- Hotlink the JavaScript from another source.

In either case, script tags had to be added to your site's HTML in the
correct order—manually handling dependency order—and the scripts
modified the window scope.

As web pages were beginning to become more complicated, this method of
doing things presented two major issues: it was common to include
resources that weren't being used, and errors attempting to use
a resource that hadn't yet been loaded.

AMD, the Asynchronous Module Definition, was created to define an API
that allowed JavaScript to be written as modules that defined their
dependencies which a loader could load asynchronously. It also had
a killer feature: used modules could be rolled into one file for
production!

While not common for most modules, some very popular libraries would
define with a specific name, to make it easy to consistently depend on
them by other libraries.

But, modules were still in the early days. Third party scripts, not
loaded by your AMD loader, might include the same popular library, but
with a different incompatible version. Including the third party script,
that didn't use AMD, might change versions of the popular library you
were using.

So AMD loaders implemented a way to signal to these popular libraries
that they had some way to protect the application developer, through
specialized loading logic, namespacing, or even warnings. AMD loaders
that implemented these protections could signal by setting a property on
define.amd to a truthy value, primarily for jQuery.

And while that was long ago, you may want to continue using modules that
expect this special handling. The “amd” configuration option allows you
to set the properties that should be exported.

Author: terinjokes

content/configuration/other-options.md

@@ -4,6 +4,7 @@ sort: 16
 contributors:
   - sokra
   - skipjack
+  - terinjokes
 ---
 
 ?> These are all the other options that might not need an entire page. Either we need to create new pages for them, move them to an existing page, or keep an **Other Options** section like this and replace this TODO with a short description/lead-in paragraph.
@@ -20,7 +21,11 @@ amd: {
 }
 ```
 
-?> I don't think this is very clear, at least not without a link pointing to what this might be used for.
+Certain popular modules written for AMD, most notably jQuery versions 1.7.0 to 1.9.1, will only register as an AMD module if the loader indicates it has taken [special allowances](https://github.com/amdjs/amdjs-api/wiki/jQuery-and-AMD) for multiple versions being included on a page.
+The allowances were the ability to restrict registrations to a specific version or to support different sandboxes with different defined modules.
+
+This option allows you to set the key your module looks for to a truthy value.
+As it happens, the AMD support in webpack ignores the defined name anyways.
 
 
 ## `bail`