webpack.md

 ### Why Webpack?
-We are choosing to use webpack as our development environment for a variety of reasons:
+We are choosing to use [webpack](http://webpack.github.io/docs/) as our development environment for a variety of reasons:
 * powerful loader/transpiler pipelines 
-* has a robust development server
+* has a robust development server (WDS--webpack-dev-server)
 * avoids the ridiculous SystemJS config that the Angular team shows in their docs
 * ability to break out entire components into webpack bundlable chunks, which could potentially be loaded independently over HTTP/2 
 * hot module replacement (right now mainly for style, eventually for entire dom components)
 
+### FYI
+* esnext-style import statements should got at the top of files; fyi, imports are converted down to es5 as calls of require()
+* requires()s can go anywhere in javascript; they're one of the first things webpack handles when parsing
+* anything imported or required ends up in one of the three bundles: polyfills.js, vendors.js, main.js
+* import third-party dependencies into the vendors.ts file (or polyfills.ts, as appropriate); this help optomize the three bundles
+* webpack can't really watch it's own config file for changes (unless you setup a little node server to run WDS for you), _so any changes to the config file require a restart of the WDS process_ 
 
-notes
-* import new dependencies into the vendors.ts file
-* config, vendors, polyfills
\ No newline at end of file
+### webpack.config.js
+* **devServer** (near the top of the module): use to configure WDS host address and port
+* **entry**: names of bundles, with the entry point files for each
+* **output**
+  - output to a directory called 'build' (this only exists in memory while using WDS)
+  - publicPath tells WDS where, relative to within the 'build' directory, to serve from
+* **resolve**: filetypes to try, in order from right to left, when there is not extension specified in the import path (i.e. `import Thing from './thing.component'`)
+* **loaders**
+  - loaders are used to convert file contents from one format into another, and/or to inject those contents into certain parts of a javascript bundle or html file, or anything else the given loader is configured to do
+  - webpack assumes there is a `'-loader'` on the end of a loader name, so `loader: 'html'` and `loader: 'html-loader'` are interchangeable
+  - _test_: regex for specifying which loaders you want to use for given file name/path matches
+  - files are fed through the specified loader(s) from right to left. e.g. *.css and *.scss files go through the sass-loader, then the postcss-loader (for autoprefixing and minification), then the raw-loader to make a string for use in ng2 components
+  - angular2-template-loader allows for simply giving a relative path for ng2 component html template files and css files rather than having to require() them first. It adds the require()s for you
+* **postcss** & **autoprefixer**: you can specify a variety of autoprefixer settings here (see https://github.com/ai/browserslist#queries)
+* **tslint**: options for tslint preLoader (see https://github.com/wbuchwalter/tslint-loader); looks at the [tslint.json file](https://dev.izeni.net/izeni/izeni-angular-template/blob/ng2/tslint.json) by default
+* **plugins**
+  - various webpack plugins used for configuration, optimization, etc
+  - _CommonsChunkPlugin_: optimizes chunks by keeping track of what has already been including, from right to left, to prevent duplication of modules
+  - _HtmlWebpackPlugin_: where to append script tags for generated bundle js files
+  - **ProvidePlugin**: for specifying variables that are global to the bundle (rather than global to the web app via a script tag in index.html); usually in the form of a key:'<node_module_name>' such as `_: 'lodash'`
+  - **DefinePlugin**: for specifying a simple bundle-global constant values (i.e. usually a string, number, or boolean), such as `NODE_ENV: 'production'` available app-wide simply by the variable name `NODE_ENV`
\ No newline at end of file