Webpack, or how to get your stuff together.

So I set out to develop my personal website and take it as an opportunity to teach myself about a level of technology that has kind of eluded me bundling; and for those of you who have had to deal with cox, no it’s not going to force you to get a phone service. This is almost essential to making anything with ReactJS work.

Where do we start? What does Webpack do? In short it does just about everything you would need to make a website work. Transpile, bundle, serve, concat, uglify…. this list just keeps getting longer as to what it can do, but the best part is it will do this all for you. What makes this all possible is the ability to map dependencies. You probably did not realize it, but when you’re building a website or app, a trail is being built, where every functional piece refers to another piece, and using this information we could essentially refactor the entire app to all fit into one file. It would be massive amounts of spaghetti code but let me illustrate.

const function1 = require(./functions) <===== this is the same as 
function1(apples);              
 
---------------------------
const function1  = function (thing) {
  console.log(thing)
}    
function1(apples)                       <====== this

Boom and just like that we’ve taken the modularity out of our code and instead of clean readible code which we understand is being held together by powers we can’t fully comprehend. We have put both of them on the same page, and gotten the same functionality. This simple concept can be applied to the entire app. Hell we can go one step further and put all of that JavaScript into the html page and it would really be an eyesore, but the computer can interpret this with ease.

You might ask, well that was neat but so what? The point I’m trying to make is that all components/pages what have you are referencing each other so we can take any one point and trace where it’s being used, what relies on it, and by doing this, map out the entire app. This means when it comes time to make your app smaller ie. concat and uglify so that your clients don’t suffer super long load times, Webpack can crawl your website and leave nothing out. This being said, There are some weird cases, which I will touch on in a later blog, but in general this is how it is done.

In order to get started with webpack just run a few install scripts. Just ignore all the -loaders for now I will expand upon what they do below.

npm install -S webpack, babel-loader, style-loader, css-loader

To take advantage of webpack you have to think in terms of mapping the app. Where does it start? The Index.html is a usual good start but I mean one step below that the Index.js. Webpack uses the term ‘Entry’ to refer to this. Now that we’ve determined where webpack is supposed to start, we have to make it do a thing, and then export that into a file which Webpack calls ‘Output’. All of these parameters are tracked in a file called, webpack.config.js, and activated with the CLI command ‘webpack’.

In the above example we’ve imported webpack, set up the entry and the output. We’ve told Webpack that the file I want start at is DEV/index.js and Webpack will crawl all the dependencies and create the result at Output/mycode.js. Since we’re just going to assume I’ve done something necessary to the functionality of my website, I’ll then make my Index.html point to this new output file, and I get all the designed functionality I want. EZPZ right! Know that this means we can have several entries and Outputs, dependent upon the needs of the page.

I said I would go over what the loaders are. While crawling the dependencies Webpack will encounter several filetypes and each filetype will require a different set of rules to map it’s dependencies. This is where the Module array comes into play. Modules will determine how webpack will incorporate the different file types.

module: {
 rules: [
   {
   test: /\.(js|jsx)$/, // Check for all js files
   use: [{
     loader: ‘babel-loader’,
     options: { presets: [‘es2015’] },
 }],
 },
]}

Since babel is so important in modern apps this is how it would be set up. We’ve acknowledged the module object, and set up an array of test’s to perform. In this case I’ve used the RegEXP which states while the file extension is .js or .jsx it will ‘use’ the loader babel to translate this file into its bundle. There are rules to just about every file extension you could think of and just have to be included into the rules array. I recommend using all the ones I have in the example. They’ll get you to a good starting place. Now all that is left to do is type in webpack, and you’ll get something like this.

Huzzah, dependencies mapped, transpiled, concatted, and awesomized. if you’re like me and used ES6 syntax with React and imported a bunch of components you may run into an error. React can resolve filepaths on your behalf, so to include them in the import statements will throw a linter error and is considered to be not best practice, however, Webpack has no idea where these imports are coming in from since it cannot resolve the filepath. ex.

import component from ./path/to/component
import component from ./path/to/component.js    <=== Same thing, but this will throw an error in your linter

To fix this issue webpack has a built in feature to handle it.

resolve: {
      extensions: ['.js', '.json', '.jsx'],
    },

Just put this handy little piece of info in your webpack.config.js just before your modules and now webpack will test each of these extensions to see what works, whenever it arrives at an unresolved file extension and fills it in for you.

These little tips are not exhaustive but if should get you started at building with Webpack, in the future I’ll go over some weird things you’ll have to do to make Webpack bundle up things like CSS files and photos, set up a dev server, how to not make your dev server file break your production file and a host of other neat tricks.