feat(content) initial release

Author: danthareja

Diff for: gulpfile.js

@@ -9,9 +9,6 @@
 var gulp    = require('gulp'),
     sync    = require('run-sequence'),
     serve   = require('browser-sync'),
-/* START SOLUTION */
-    webpack = require('gulp-webpack');
-/* END SOLUTION */
 
 /*
  * A convenience object to hold different paths we care about.
@@ -23,26 +20,8 @@ var paths = {
   app: ['client/**/*.{js,css,html}']
 };
 
-/* START SOLUTION */
-/*
- * Gulp is built ontop of node's powerful 'stream' concepts.
- * You can think of a stream as faucet of water that flows through different 'pipes'
- * We open the gulp faucet by passing a glob of files into gulp.src.
- * Then we can 'pipe' these files through all sorts of different transformations,
- * each one returning its own stream that can continue to be piped into more transformations.
- *
- * Here, we're grabbing the entry point to our (making the `entry` property in webpack.config.js unnecessary),
- * piping the entry into webpack plugin, bundling our app, and piping that into the client folder designated by gulp.dest
- *
- * NOTE: gulp.dest defines our webpack's output folder. Webpack will get mad if it finds an output.path property 
- * in webpack.config.js. We still need `filename` though.
-*/
-gulp.task('build', function() {
-  return gulp.src('./client/app.js')
-    .pipe(webpack(require('./webpack.config.js')))
-    .pipe(gulp.dest('client'));
-});
-/* END SOLUTION */
+// TODO: Write a `gulp build` task that uses webpack to build your app and output it to `client/bundle.js`
+// HINT: Some properties that are needed to run `webpack` from the CLI are unnecessary when paired with gulp
 
 /*
  * Browsersync manages a server that plays nicely with gulp (see serve.reload below)
@@ -83,5 +62,5 @@ gulp.task('watch', function() {
  * and then invoke the `done` callback to let gulp know all asyncronous tasks have been completed.
  */
 gulp.task('default', function(done) {
-  sync(/*START SOLUTION*/'build'/*END SOLUTION*/, 'serve', 'watch', done);
+  sync('serve', 'watch', done);
 });

Diff for: webpack.config.js

@@ -1,4 +1,3 @@
-/* START SOLUTION */
 /*
  * This is where we tell Webpack exactly what we want it to do.
  *
@@ -8,59 +7,4 @@
  *   3) What we want to do with the files in our app (module.loaders)
  */
 
-module.exports = {
-  /*
-   * Organizing our code in modules is a bit different than the traditional style.
-   * Gone are the days of endless <script> tags in index.html that must be carefully ordered.
-   * Instead, our `entry` point defines where our app starts. It's here where we'll import
-   * all other files as needed, and Webpack manages the tree of dependencies automagically.
-   * 
-   * If you've ever used node, your app's entry point is conventionally `index.js`
-   */
-  // entry: './client/app.js', (unnecessary with gulp - gulp.src does this for us)
-
-  /*
-   * Not only will Webpack gracefully manage the tree of dependencies for us, it can also
-   * smash all the dependencies into one convenient file that we can send over the wire.
-   * This is similar to minification. The `output` object defines where this minified file should live
-   */
-  output: {
-    // path: __dirname + '/client', // Absolute (!) path for our output file (unnecessary with gulp - gulp.dest does this for us)
-    filename: 'bundle.js', // `bundle.js` is a typical convention for Webpack
-  },
-
-  /*
-   * Bundles are all fun and games until you have to debug them. It's not easy
-   * sorting through one giant file of transpiled ES5 code to see where you went wrong.
-   * 
-   * Sourcemaps are an invaluable tool when debugging. They map your bundle to your
-   * source files and allow you to trace errors in your bundle back to the code you
-   * actually wrote. You should always use source maps when developing with a transpiler.
-   */
-  devtool: 'sourcemap', // Will be created at './client/app/bundle.js.map'
-
-  /*
-   * This is where most of magic happens. Webpack loaders allow you to preprocess files as you import them.
-   * They are kind of like 'tasks' in other build tools. In fact, if you are using another build tool
-   * like gulp or grunt along with Webpack, you should leave any task that touch files
-   * (transpilation, minification, etc) to Webpack and use your other build system to orchastrate other automation.
-   *
-   * Loaders can tranform files from a different language (TypeScript to JavaScript or ES6 to ES5!)
-   * Loaders even allow you to do things like import css files right in your JavaScript!
-
-   * Each loader is just an object that defines (1) a collection of files (2) the transformation.
-   * Here's how the properties work: 
-   *   test: A condition that must be met (regex)
-   *   loader: A string of "!" separated loaders (these are executed from right to left)
-   *   include: A condition that must be met (not included, but reges)
-   *   exclude: A condition that must not be met (regex)
-   */
-  module: {
-    loaders: [
-      { test: /\.js$/, loader: 'babel', exclude: [/node_modules/]}, // Transpile our .js from ES6 to ES5
-      { test: /\.html$/, loader: 'raw' }, // 'raw' will import our html as a string - great for Angular templates!
-      { test: /\.css$/, loader: 'style!css' } // 'css' loader will parse our stylesheets, and 'style' loader will inject it into the <head> of our index.html
-    ]
-  }
-};
-/* END SOLUTION */
+module.exports = {};