tldr: Changing `module` config changes the syntax used to import/export in the compiled code. The new value, "ES6", means that the code compiled by TS will include import/export statements. That code is then further compiled by Webpack, which removes the imports/exports during concatenation.

Using ES6 import/exports in the typescript output improves Webpack's tree-shaking. (Or really...enables it. I believe webpack does not treeshake unless the input uses ES6 import/export syntax.)

Related:

TS has several sort of settings related to the syntax used in output:

- `lib`: determines the default/builtin type definitions that are included when typechecking your code.
- `target`: Spcecies environment in which your code is going to run, and controls how Typescript downlevels your code.

    > "The `target` setting changes which JS features are downleveled and which are left intact. For example, an arrow function `() => this` will be turned into an equivalent function expression if target is ES5 or lower."

    `target` determines the default value of `lib`. If `target` is ES5, you probably want `lib` to be ES5, too, unless you're doing further transpilation with another tool (like babel).
- `module`: Determines the syntax used for exports.
- `moduleResolution` determines how module identifiers ("some/thing" in  like `import x from "some/thing"`) are interpretted.

* refactor: old course theme removed

* removed some old course theme files from base theme

Nanogallery2 includes hammerjs, screenfull, shifty, and images loaded as modules embedded in its source code; see https://github.com/nanostudio-org/nanogallery2/blob/d6056652705360e19ab330095f489f438a9e9d1c/src/jquery.nanogallery2.core.js#L11-L15.

In browsers, Nanogallery2 intends to expose those objects on the global Window.

However, bundling with Webpack messes up the way Nanogallery2 exposes those objects. (NG checks if `exports` is undefined, but Webpack defines an `eports` object itself.) Consequently, naive inclusion of Nanogallery2 in a webpack build does not work.

To work around this, we previously were including those 4 dependencies separately and manually attaching them to global Window object, which is the workaround suggested at nanostudio-org/nanogallery2#98 (comment).

This approach has several downsides, e.g:  extra js; need to make sure we are including the correct versions of the 4 dependencies.

A cleaner approach is to use imports-loader, as suggested nanostudio-org/nanogallery2#98 (comment).