DEV Community: Nitish Dayal

Setting Up VS Code and iTerm on M1 Macs

Nitish Dayal — Mon, 14 Dec 2020 13:42:01 +0000

Let's answer some questions:

Why are you writing this?
Because some stuff doesn't 'just work' when restoring from an old backup. I was gifted an M1 Mac Mini (thanks, girlfriend!) and tried to set it up with a backup from my Macbook Air. While some things worked, other things went horribly wrong. And going through the process of resetting an M1 Mac product is a pain¹ in the² ass³, so I'm attempting to save you the headache.
But I restored from a backup and mine works fine!
Great! Mine didn't.
Okay, so what do you recommend?
Start from scratch. Yeah, I know. It's not fun. But it doesn't have to be entirely terrible!

Prerequisites

Enable Settings Sync in Visual Studio Code and sync your settings from your current machine
Save your .zshrc in a Github Gist or something of the sort.

Visual Studio Code

Once you've got your settings from VS Code on your existing machine synced up, install VS Code on your new machine, enable Settings Sync, and...sync your settings. Easy. All of your extensions will get installed, your settings will be synced, and you'll be set. If you were using a custom font (Fira Code, Dank.sh, Monoid, whatever floats your boat) go and install that. Done.

UPDATE: Visual Studio Code Insiders just released a version compatible with M1 Macs! Link: VS Code ARM64

iTerm

Once you install iTerm 2, you'll probably want to install Homebrew, Oh My ZSH!, NVM and whatever else. Before doing anything, go to your Applications folder, right-click on iTerm, click 'Get Info', and check the 'Open using Rosetta' option.

Before I did this, I was getting a bunch of undecipherable errors from various command line tools because (presumably) they have compatibility issues with the M1 chip. There are alternative solutions, but I found this to be the easiest to implement and the most out-of-sight-out-of-mind solution. Check the option and don't worry about it. From there you should be able to install all your shell integrations and command line tools with no problem. I was able to install Homebrew and some formulas, NVM, Python 3, and Mac CLI with no issues.

Create or update your .zshrc file with your existing configuration which you should have uploaded to a Github Gist, and you're set.

Or. At least I was set. 😅 Good luck!

How I Dealt With Imposter Syndrome

Nitish Dayal — Tue, 08 Dec 2020 17:43:24 +0000

Disclaimer: This post will be inevitably anecdotal, will probably be all over the place (I haven't written anything in years), and will most likely ooze with survivorship bias. If it feels like the things I talk about don't apply to you, that's fine. Everyone's journey is different. I wanted to share this in the hopes that even one person would get something out of it.

After one year of unemployment, I finally landed a job as a frontend engineer. 😄 In this post I'll share a little about who I am, what led to this one year gap in my employment, and what I did to get back into the industry.

If you're exclusively interested in learning about how I approached the application and interview process, just skip to the last two parts. The rest of the post is about who I am and how I dealt with some particularly crippling imposter syndrome.

Who I Am
The One Year Gap
Applying and Interviewing
Conclusion

Who Am I (professionally)

Basics: 30 year old Indian guy, raised in the US since I was 7. Another Javascript person, mostly client-side.

Education: High school diploma, dropped out of a bunch of colleges, 2015 coding bootcamp grad (name doesn't matter, they're basically all the same).

Prior experience: 10 years in retail, sales, and banking. Was fairly successful; I was able to survive off of my income and support myself, but the job wasn't particularly rewarding and upward mobility didn't seem to alleviate that.

Industry experience:

10mos as an Assistant Instructor at aforementioned coding bootcamp
4mos with a small start-up, helping them migrate from AngularJS to Angular (at the time, 2.0)
2yrs 5mos at Amazon as a Web Development Engineer; 1 yr working on the retail side, 1yr 5mos on the API Gateway console team

The One Year Gap

tldr; Left Amazon in September of 2019, spent next 6mos dealing with family stuff, then entered the job market in a world of COVID and imposter syndrome, wasted a bunch of time telling myself I sucked, started another bootcamp, and didn't apply for a job until November.

I left Amazon in September of 2019. I wasn't enjoying the work, after switching teams I found it very difficult to gain any form of mentorship, and I found myself constantly butting heads with management. It reached a point where going into the office had become the primary source of stress in my life. While it would have been better to seek out employment before leaving my job, I don't regret the way I did things. I was miserable and I did what I had to do for my mental health.

Shortly after leaving, there was a medical-related family emergency that came up, and I chose to prioritize that over getting back to work. It was March of 2020 when things finally settled down and I was able to focus on looking for a job. Not only was COVID-19 in full effect, 6 months had passed since I had actively participated in the web development world. Given the pace at which that world moves, I felt very out of touch. Browsing through Twitter fueled my imposter syndrome; I had no clue what the hell anyone was talking about. "Are my skills even relevant any more? Do I need to learn <insert-trending-library/framework/technology/language-here>? Should I ~just build stuff?" I had no clue where to start.

I ended up splitting my time between going through Web Development fundamentals, Javascript fundamentals, and learning various trending libraries (Vue, Svelte, whatever else). No matter what I did, I couldn't help but feel like I was wasting time and not learning skills that would help me find employment. Going through the fundamentals felt tedious; I knew all of the subjects covered. I already had a career in this field. I should be qualified. But when I would look at job descriptions, I would think to myself 'no, no, I need to learn more before I can apply.' I was just talking myself out of applying. Between September 2019 and August 2020, I submitted 0 job applications. I would find jobs, read the job description, tell myself I wasn't qualified, not apply, and then go do some more beginner courses. I am not a beginner. To be clear, there is nothing wrong with being a beginner. I'm just not one. So, while an argument could be made that going through these courses cemented my understanding and built a strong foundation, it wasn't a particularly good use of my time. I should have either learned new topics that I wasn't familiar with, or focused on building projects to add to a portfolio.

I eventually convinced myself that the best thing I could do for myself was to immerse myself in programming and web development again. While I might not have the nicest things to say about bootcamps, I acknowledge that they are very good for one thing: providing an environment conducive to learning made up of highly motivated individuals. So I signed up for another bootcamp, hoping that it would help me build some confidence regarding my knowledge and skills, and that I would be able to create projects to add to my portfolio. And the bootcamp experience did just that. I found that I was familiar with all the topics discussed. I had done this stuff before for a profession. I can do it again.

Applying and Interviewing

How I learned about the opportunity: I was talking with a friend of mine about my past experience at Amazon and why I left, and we got on the topic of what I was looking for in a team. After some discussion, he recommended I apply to the company he works for. He was close with one of the leads for the web development team, and he felt like my goals aligned with what the team was aiming to achieve.

The interview process: After sending my resume to my friend, I was contacted by one of their internal recruiters for a 20 minute interview. This interview was a 'get to know you' interview. The recruiter asked me about my past experience, the gap in my employment history, my education, what I was looking for in a career, why I wanted to work at this company...I wasn't asked any technical questions. After a day, I was contacted again by the recruiter about setting up a 45-min interview with the Senior Director for Web Technologies. I asked the recruiter if this would be a technical interview, and they told me it would be a mix.

This interview, again, started with the standard 'get to know you' questions. You should have consistent, practiced responses to these questions. Having concise, rehearsed responses will help you sound confident in the interview and will help the conversation move forward quickly. It's okay if you have a few 'um's and 'uh's in your answer, but you want to avoid long silences while you try to formulate a response. Think about common non-technical interview questions ("Tell me why you want to work here", for example), or find a list of them online, and prepare answers for them. Practice saying those answers out loud.

After those questions, we got to the technical part of the interview. Given that this interview was over the phone, it was more of a knowledge check than anything else. Could I confidently speak about scope in Javascript? Did I understand hoisting? Did I understand what the purpose of a Promise is? How would I create a two-column layout using CSS? How would I tell a browser that a cached asset is no longer valid? I wasn't asked to write any code, but I had to be able to speak confidently about topics that were relevant to web development fundamentals. Being able to write code is obviously important, but it's arguably more important to be able to talk about your code. In a team environment, communication is key. Being able to talk through how you approach a problem is just as important as writing out your solution. At the end of this interview, I made sure to ask what the next steps would look like. If there's only one question I urge you to ask when your interviewer says "do you have any questions for me?", I think this is the one. Regardless of however many books and articles people can release on the topic, the tech interview is shrouded in mystery because it changes from one company to the next. Don't be afraid to ask what comes next. You want to be able to prepare for success, and hopefully the company you're interviewing with wants you to succeed.

The final interview was to be a 3hr 'remote onsite'. Basically, I was to sit in front of a webcam and go through the interview gamut with a bunch of seniors, managers, leads, etc. I knew this would be purely technical, but I had no idea what kind of questions would be asked of me. Would I be asked about data structures and algorithms? Would it be more relevant to web development?

Nitish Dayal

@nitish_dayal

If they ask a bunch of Javascript stuff, I'll be fine. If someone asks me to implement and traverse a BST, I might just respond with 'google it'.

14:31 PM - 02 Dec 2020

0 1

I had no clue. So I reached out to some current employees and members of the web development team on LinkedIn and asked them. There's no harm in doing this. It takes very little effort, and the worst that could happen is that you don't get a response, in which case you'd be exactly where you started. No big deal. Thankfully, someone did respond to me and confirmed that the interview questions would be centered around web development, with some questions around architecture, client/server best practices, and working in a team environment.

Every person I spoke to during this interview started with the same 'get to know you' questions. Again, practice your responses to these. Get your answers down so you can get to the rest of the interview and show off what you know. The technical questions were in line with what I was told, and for the most part I wasn't caught off guard, but there were a few times I was stumped.

Nitish Dayal

@nitish_dayal

Crushed first two parts of the interview, was feeling great. Next interviewer is Chief Engineering Officer. ‘How would you implement a micro front-end? What would the architecture look like?’

Shit.

00:24 AM - 03 Dec 2020

0 3

In those moments, I made sure to maintain some level of confidence, and tried to talk through my thoughts and how I was trying to solve the problem. Having all the right answers is great, but when you're on the job, there will inevitably be a problem that you don't know how to solve. What's more important than getting the right answer to every question is to be able to explain your thought process, and walk through your approach to problem-solving.

I was contacted 3 days after the interview and was presented with an offer.

Conclusion

Lots of words. What I hope you can take away from this:

Don't doubt your skills. If you do, ask yourself what you need to do to alleviate those doubts, and do it.
Don't listen to all the Twitter hype or buy into the FOMO. Obviously this is easier said than done, but do what you can to turn away and just focus on yourself. That time scrolling through Twitter and reading about the hot new thing Thoughtleader X is selling to their 40k followers is probably better spent just...doing stuff.
A gap in your employment experience is fine. When asked about mine, I tried to explain it as transparently as I could. I wasn't shy or ashamed of it. It's just a part of my experience.
If you're invited to interview with a company, do what you can to learn about their interview process. Reach out to people who work there with the title that you're applying for, or work at the department you're applying to, and ask them what you can expect. Search for '<company name> interview process <job title>' or something along those lines, and see if anything relevant comes up. The more surprises you can eliminate, the better your chances are.
It's okay if you don't have an answer to a question off the top of your head. Talk through it. Ask questions to gain more insight into the problem you're being asked to solve. Talk about how you would approach solving it.

I was very fortunate that the first place I applied to was willing to hire me, but I can't help but wonder how much sooner I could have had a job had I listened to same advice I listed above. I hope this information motivates at least one other person to feel confident about themselves, and to go out there and apply.

Thanks for taking the time to read! 😄 If you'd like to connect, you can find me on Twitter.

Stages of Learning Webpack, Pt. 3 - SourceMaps, Loaders, & Plugins

Nitish Dayal — Sun, 18 Jun 2017 05:59:58 +0000

Intro

This article is a continuation of the Stages of Learning Webpack series. The repository containing the source code has been updated since the last article to include the latest versions of all dependencies as well as some configuration improvements (read: I might've made a lot of goofs the first time around).

Github Repo

Step 2, Cont.

At some point, you'll need to debug your application. Most modern browsers provide intuitive developer tools which can assist in debugging and optimizing your application.

In your text editor, change the first line in src/app/sayHello.js to the following:

export default name => alet(`Hello ${name}`);

We've placed an intentional error in our application by misspelling alert as alet. From the command line, run npm run build/yarn build. The build should still succeed; Webpack is not responsible for maintaining the accuracy of our JavaScript code. Open the index.html file in your browser and open your browser's developer tools. There will be an error message along the lines of ReferenceError: alet is not defined.

Clicking on the filename to the right of the error message will navigate us to the line & column of the file in which the error occurred. Since our index.html file is using the generated Webpack bundle to load our JavaScript code, we'll be pointed to the line in the generated Webpack bundle at which the error occurred. From there, it's up to us to work our way backwards from the point of error in the bundle to the point of error in our actual source code.

If that's what's involved in debugging, then I'm not debugging any more. There must be an easier way. We can do better. We have the technology.

Step 3

Branch: sourceMaps

Let's start by looking at the differences between this branch (sourceMaps) and the previous (init):

Changes to `webpack.config.js`:

We've added a new key to the Webpack configuration object; the devtool key. The value associated with this key depends on the value of the argument env.

module.exports = env => ({
  devtool: (env && env.production) ? "source-map" : "cheap-eval-source-map",
  entry: "./src/index.js",
  output: { filename: "./build/bundle.js" },
  resolve: { extensions: [".js"] }
});

We can rewrite the file in ES5 as:

module.exports = function(env) {
  var devtool;

  if (env !== undefined && env.production === true) {
      devtool = "source-map";
  } else {
      devtool = "cheap-eval-source-map";
  };

  return {
    devtool: devtool,
    entry: "./src/index.js",
    output: { filename: "./build/bundle.js" },
    resolve: { extensions: [".js"] }
  };
};

First, we declare a variable devtool. Then, if the env argument isn't undefined and env is an object with a key/value pair { production: true }, then define the value of devtool as a string "source-map". Otherwise, define devtool as "cheap-eval-source-map". The meaning associated with these values will be explained later; for now, I want to be clear that all we've done is create a variable, and define that variable as a string. The value of that string is dependent on a conditional statement (the if/else block).

Finally, we return an object with a set of key/value pairs that Webpack can use to create our bundle. The entry, output, and resolve key/value pairs have been carried over from the init branch.

Changes to `package.json`:

We've updated the scripts section of the package.json file.

Before:

/*...*/
  "scripts": {
    "build": "webpack"
  },
/*...*/

After:

/*...*/
  "scripts": {
    "dev": "webpack",
    "prod": "webpack --env.production"
  },
/*...*/

The name of the command which calls Webpack has been changed from build to dev. The naming convention implies that this will create a development version of the bundle, and this is true. We're not having Webpack run any sort of optimization when it creates the bundle. Our configuration just says 'take this entry file (src/index.js) and every file it imports, bundle them all together, and output that bundle as a file (./build/bundle.js).

There is also a new key, prod. Again, the naming convention implies that this will create a production version of the bundle. It doesn't. Yet. But it will! Right now, the only difference between the prod script and the dev script is that we're now passing an argument to the exported function in webpack.config.js as the env argument, which the function then uses to create and return the Webpack configuration object. To see this in action, you can place a console.log(env) statement inside the function exported from webpack.config.js.

// webpack.config.js
module.exports = env => {
  console.log(env);

  return {
    devtool: env && env.production ? "source-map" : "cheap-eval-source-map",
    entry: "./src/index.js",
    output: { filename: "./build/bundle.js" },
    resolve: { extensions: [".js"] }
  }
};

From the command line, run the command npm run dev/yarn dev.

> webpack

undefined
Hash: 9d81a1b766e4629aec0c
Version: webpack 2.6.1
Time: 82ms
            Asset     Size  Chunks             Chunk Names
./build/bundle.js  5.75 kB       0  [emitted]  main
   [0] ./src/app/sayHello.js 233 bytes {0} [built]
   [1] ./src/index.js 453 bytes {0} [built]

That undefined right after > webpack is our console.log(env) statement. It's undefined because we didn't pass any additional arguments to Webpack in our dev command. Now, let's run the npm run prod/yarn prod command from the command line.

> webpack --env.production

{ production: true }
Hash: cbc8e27e9f167ab0bc36
Version: webpack 2.6.1
Time: 90ms
                Asset     Size  Chunks             Chunk Names
    ./build/bundle.js  3.79 kB       0  [emitted]  main
./build/bundle.js.map  3.81 kB       0  [emitted]  main
   [0] ./src/app/sayHello.js 233 bytes {0} [built]
   [1] ./src/index.js 453 bytes {0} [built]

Instead of seeing undefined, we're seeing an object with one key/value pair { production: true }. These values match up with the conditional statement in our Webpack configuration; our conditional statement ensures that the argument env isn't undefined, and that it is an object with a key/value pair { production: true }. You might have noticed that the generated bundles from the commands are different as well. The bundle generated with the dev command is larger than bundle generated by prod, however the prod command generated an additional file bundle.js.map.

Open the file src/app/sayHello.js. Since this is a different branch of the Git repository, the error we previously placed in this file might not carry over if the changes were made in the init branch. If that's the case, change the first line so that the alert call is misspelled as alet. Save your changes, then run npm run dev/yarn dev from the command line again. Open index.html in your browser, then open the browser's devtools. You should have an error in the console stating alet is not defined.

If the console claims that this error is being generated in the index.html file, refresh the page. You should see something along the lines of:

ReferenceError: alet is not defined          sayHello.js?7eb0:1

Clicking on this error should take you to the line & file in which the error occurred, but you'll notice that the entire line is highlighted as an error. In this case, that's not entirely inaccurate. But let's say we change the src/app/sayHello.js file around again. This time, we'll change the reference to name inside of the alert call to be namen:

export default name => alert(`Hello ${namen}`);

export const donut = "I WANT YOUR DONUTS";

/**
 * Same code, ES5 style:
 * 
 * function sayName(name){
 *    return alert('Hello ' + name);
 * }
 * 
 * export default sayName;
 * 
 */

Run npm run dev/yarn dev from the command line again, and refresh the index.html file that's open in your browser. The console in your devtools should display a similar error message; namen is not defined. Clicking on the error message will, again, take us to the line in which the error occurred.

Now, run npm run prod/yarn prod from the command line, and refresh the index.html file in your browser. Open your devtools and look at the error in your console, the filename is now just sayHello.js. Clicking on the error navigates us not only to the file & line in which the error occurred, but also the column in which it occurred. The error underline is more specific as well; it begins at namen as opposed to underlining the whole first line.

And that's the difference between the two commands; the accuracy of the source maps they generate. The reason we use a less accurate version of source maps for development purposes is because they are faster to generate than to have Webpack generate full source map files each time we create a build. You can learn about the different options for source mapping with Webpack here: Webpack Devtool Configuration.

Step 4

Branch: loader

Notice that the generated bundles maintain all ES2015 syntax used in the source files; let & const, arrow functions, newer object literal syntax, etc. If we tried to run our application in an older browser which didn't have support for these features, the application would fail. This is where we'd usually take advantage of a transpiler such as Babel, TypeScript, CoffeeScript, etc. to run through our code and translate it to a version with better cross-browser support. The loader branch covers how to integrate TypeScript into our Webpack build process in order to transpile our application code down to ES3 syntax. Note that we don't introduce any TypeScript-specific features; I even leave the files as .js files. We'll be using TypeScript as an ESNext --> ES3 transpiler.

Strap in folks; this one's gonna be bumpy.

Dependencies

Looking at the package.json file, we've added two new developer dependencies.

TypeScript: As stated earlier, we'll use TypeScript as our transpiler.
TS-Loader: Loaders allow Webpack to understand more than JavaScript. In this case, TS-Loader allows Webpack to use TypeScript to load TypeScript (and JavaScript) files and transpile them based on your TypeScript configuration before generating a browser-friendly bundle.

To install these dependencies, run npm install from the command line. NPM should read the package.json file and install the dependencies as listed. In general, to install additional developer dependencies, you can run npm i -D <package-name>, where <package-name> is the package you want to install, ie: npm i -D typescript. The -D flag tells NPM to save the installed package as a developer dependency.

The prod command has been updated as well; it now includes the flag -p. The -p flag is an option that can be provided to the Webpack CLI (command line interface, the tool that NPM calls on when a script in the package.json file uses webpack) which provides optimizations for a production environment. We'll take a deeper look at this shortly.

TypeScript Configuration

The tsconfig.json file provides information for TypeScript to utilize when transpiling our code.

{
  "compilerOptions": {
    "allowJs": true,
    "module": "es2015",
    "target": "es3",
    "sourceMap": true,
    "strict": true
  },
  "include": [
    "./src/"
  ],
  "exclude": [
    "node_modules/",
    "./build/"
  ]
}

This configuration object tells TypeScript a few things:

TypeScript is generally used to transpile TypeScript files (.ts) into JavaScript. By setting allowJs to true, we're allowing TypeScript to transpile .js files.
TypeScript is capable of transpiling JavaScript to work with a variety of module systems. We're telling TypeScript to use the ES2015 module system because Webpack is able to apply some pretty nifty optimizations when applications are created using this variation.
We can target most JavaScript versions from ES3 to ESNext. Given that we're aiming for BETTER browser support, not horrendously worse, we go with ES3.
Generate source maps for each transpiled file.
Use all the strict type-checking features that TypeScript offers.

Webpack Configuration Updates

module: {
  devtool: env && env.production ? "source-map" : "inline-source-map",
  /* ... */
  rules: [
    {
      test: /\.js(x)?/,
      loader: "ts-loader",
      options: {
        transpileOnly: true,
        entryFileIsJs: true
      }
    }
  ]
}

We've introduced a new key to the Webpack configuration object; module. The module section provides information to Webpack regarding how to work with certain files that are utilized throughout the application. We've provided one rule, which can be read as such:

When Webpack comes across a file ending in .js or .jsx, it will first pass the files to TS-Loader before generating a the requested bundle. TS-Loader is responsible only for transpiling the application; we are not using any of the type-checking features provided by TypeScript.

The type of source map used for development environments has been changed from "cheap-eval-source-map" to "inline-source-map". The differences between these two options are covered in the Webpack documentation: here: Webpack Devtool Configuration.

Run npm run dev/yarn dev from the command line and open the index.html file in your browser. Everything should work as expected. Look at lines 73-105 in the generated bundle:

"use strict";
/* unused harmony export donut */
/* harmony default export */ __webpack_exports__["a"] = (function (name) { return alert("Hello " + name); });;
var donut = "I WANT YOUR DONUTS";
/**
 * Same code, ES5 style:
 *
 * function sayName(name){
 *    return alert('Hello ' + name);
 * }
 *
 * export default sayName;
 *
 */


/***/ }),
/* 1 */
/***/ (function(module, __webpack_exports__, __webpack_require__) {

"use strict";
Object.defineProperty(__webpack_exports__, "__esModule", { value: true });
/* harmony import */ var __WEBPACK_IMPORTED_MODULE_0__app_sayHello__ = __webpack_require__(0);

// Import whatever the default export is from /app/sayHello
// and refer to it in this file as 'Hello'
var name = "Nitish";
// Reference to the <div id="root"> element in
var root = document.getElementById("root");
// Call the function that was imported from /app/sayHello, passing in
// `const name` that was created on line 5.
__webpack_require__.i(__WEBPACK_IMPORTED_MODULE_0__app_sayHello__["a" /* default */])(name);
root.textContent = "Helllloooo " + name + "!";

All const and let declarations have been converted to var. The template strings used in the alert message and for root.textContent have been replaced with string concatenation. Our bundle was created using the transpiled code generated by TypeScript.

If we remember from earlier, src/app/sayHello.js exports two items; a function as a default export, and a constant donut as a named export.

export default name => alert(`Hello ${name}`);

export const donut = "I WANT YOUR DONUTS";

The second export isn't used anywhere in the application, but it's still included in the bundle. However, if we run npm run prod/yarn prod and take a look at our bundle then...

It's a hot mess! Here's a (nicer, formatted) look at the bundle:

!(function(t) {
  function e(r) {
    if (n[r]) return n[r].exports;
    var o = (n[r] = { i: r, l: !1, exports: {} });
    return t[r].call(o.exports, o, o.exports, e), (o.l = !0), o.exports;
  }
  var n = {};
  (e.m = t), (e.c = n), (e.i = function(t) {
    return t;
  }), (e.d = function(t, n, r) {
    e.o(t, n) ||
      Object.defineProperty(t, n, { configurable: !1, enumerable: !0, get: r });
  }), (e.n = function(t) {
    var n = t && t.__esModule
      ? function() {
          return t.default;
        }
      : function() {
          return t;
        };
    return e.d(n, "a", n), n;
  }), (e.o = function(t, e) {
    return Object.prototype.hasOwnProperty.call(t, e);
  }), (e.p = ""), e((e.s = 1));
})([
  function(t, e, n) {
    "use strict";
    e.a = function(t) {
      return alert("Hello " + t);
    };
  },
  function(t, e, n) {
    "use strict";
    Object.defineProperty(e, "__esModule", { value: !0 });
    var r = n(0), o = document.getElementById("root");
    n.i(r.a)("Nitish"), (o.textContent = "Helllloooo Nitish!");
  }
]);
//# sourceMappingURL=bundle.js.map

It's still a hot mess! There isn't much of a need to manually parse through this; it's 38 lines of IIFE goodness, so it's doable, but there's no obligation and it won't assist with the rest of this guide. What I'm trying to show here is that the generated production bundle has no reference to the line const donut = "I WANT YOUR DONUTS!";. It's completely dropped from the bundle. Along with the minification, uglification, and handful of other out-of-the-box production optimizations Webpack is capable of implementing when provided the -p flag, tree-shaking is part of that list. I didn't have to do anything to enable tree-shaking; it Just Works™.

Excellent! We're transpiling our ES2015+ code down to ES3, removing any unused code along the way, and generating a production(ish)-quality bundle that can be loaded by most modern browsers with errors and warnings pointing back to our source code for simplified debugging.

Step 5

Branch: plugin

Plugins do exactly what they say on the tin; they plug into the build process to introduce extra functionality. In this example, we'll get introduced to HTMLWebpackPlugin, a plugin for generating HTML documents which can serve our Webpack bundles.

As it stands, we created an HTML file which points to the expected bundle. In simple situations, a setup like this would work fine. As the application grows, the bundle could get split into more than one file, The filenames might be randomly generated, etc. If we were to try and manually maintain the list of files that need to be loaded into our HTML file...well, we're kind of back to square A, right? We'll use HTMLWebpackPlugin to automate the process of loading our bundles into our HTML document.

File Changes

Introduced a new developer dependency to the package.json file; HTMLWebpackPlugin. Make sure to run npm install/yarn when you've switched to this branch to get the necessary dependencies.

    "devDependencies": {
      "html-webpack-plugin": "^2.28.0",
      "ts-loader": "^2.1.0",
      "typescript": "^2.3.4",
      "webpack": "^2.6.1"
    }

The index.html file no longer loads the build/bundle.js file.
webpack.config.js has been updated to include a CommonJS style import statement (const HTMLWebpackPlugin = require("html-webpack-plugin");) at the top of the file, and has a new section, plugins:

    //webpack.config.js
    const HTMLWebpackPlugin = require("html-webpack-plugin");

    module.exports = env => {
      /*...*/
      plugins: [
        new HTMLWebpackPlugin({
          filename: "./build/index.html",
          inject: "body",
          template: "./index.html"
        })
      ]
    }

We're telling Webpack that we'll be using HTMLWebpackPlugin to generate an HTML file named index.html inside of the build folder. HTMLWebpackPlugin is to take any generated bundles and inject them into the body of the HTML file in script tags. It will use the existing index.html found in our application root as a template.

If we call on npm run dev/yarn dev or npm run prod/yard prod, we should see something similar to:

$ npm run dev

> webpack -p --env.production

ts-loader: Using typescript@2.3.4 and /Projects/dev_to/webpack_configs/example/tsconfig.json
Hash: 693b4a366ee89bdb9cde
Version: webpack 2.6.1
Time: 2233ms
             Asset       Size  Chunks             Chunk Names
 ./build/bundle.js    8.96 kB       0  [emitted]  main
./build/index.html  352 bytes          [emitted]

Based on the configuration provided, Webpack generated the requested bundle along with an index.html file. The generated index.html file looks very similar to our existing template, but carries a reference to the generated Webpack bundle inside of the document body.

Open the new index.html file (./build/index.html) in your browser to make sure everything works as expected.

Now stand back, rejoice in your work, and soak it all in. You're on your way to Webpacking the world, amigos.

How do you practice programming?

Nitish Dayal — Sun, 28 May 2017 18:38:07 +0000

The idea came up when I was playing guitar. I play because I like to play, no professional aspirations or anything like that, but I still put in actual practice hours. Practicing usually involves a collection of exercises that:

Are fun to play.
Build on different parts of fundamentals (picking techniques, arm/wrist movement, fretting hand positioning, etc.).
Provide ways to measure progress.

And then I realized I have nothing like this when it comes to programming. I have a solid system for learning stuff (read the docs and headdesk until things work ðŸ‘ðŸ¾), but nothing when it comes to practicing. I've tried algorithm-challenge style books and websites, but frankly they're just stressful. Was hoping to hear from the Dev.to community regarding what options are available and works for y'all. ðŸ‘¨”ðŸ’»

If more specific questions are preferred: How do you practice? How do you decide what to practice? Have you tried other methods? How is practicing different from learning? As in depth or as concise as you'd like, just happy to hear some ideas and recommendations.

Stages of Learning Webpack, Pt. 2 - The Config

Nitish Dayal — Mon, 22 May 2017 09:27:37 +0000

DISCLAIMER: Webpack isn't the only option for module bundling. Module bundling isn't even the only option for solving the client-side module 'issue'. There's a whole lot of ways to do this stuff. I'm gonna take a crack at explaining some Webpack things because that's what I've been working with. + my grammar isn't fantastic, and my vernacular is a mix of wannabe intellectual and obnoxious child. You've been warned.

This was supposed to go up last week, but things happened. ðŸ¤· The original draft was consumed by an unexpected system restart + me not saving my progress on the Dev.to platform, and on the second attempt I realized that trying to fit everything I mentioned at the end of my first post would lead to either a post which wouldn't go deep enough to be valuable, or one which would cause information overload. Instead, I'm going to break that content up into multiple posts.

The goal of this post is to explain what Webpack is by exploring the problem it attempts to solve, and to go over the basics of a Webpack configuration. The content will be targeted towards those who are new to the Webpack ecosystem. I don't know how much further above 'beginner' I would consider myself with Webpack, so if you're fairly seasoned read on regardless and provide feedback. ðŸ˜ƒ There are a LOT of other posts similar to this one. I'm standing on the shoulders of slightly deprecated content.

Introduction - The Problem With Client Side Modules

As users have come to expect more from their applications, client-side JavaScript development has evolved to meet those expectations. We're at a point where placing all your code in one JavaScript file can become very unwelcoming, very quickly. Applications are developed by splitting a codebase into small, relevant chunks and placing those chunks in individual files. These files are called JavaScript modules. When a piece of code in fileA.js is needed in fileB.js, that code can be imported into fileB so long as it was exported in fileA. In order to load these files into the browser, the approach when working with a more manageable number of files would be to add <script> tags as necessary. This is feasible when working with a handful of files, but applications can quickly grow to a point where manually loading all the files would be very, very complicated. Not only would you be responsible for making sure that all the files were properly referenced in your root document (main index.html file, whatever you call it), you would also have to manage the order in which they were loaded. I don't want to have to do that with 100+ files.

For example, here is the directory structure from my boilerplate:

  â”œâ”€â”€ LICENSE
  â”œâ”€â”€ README.md
  â”œâ”€â”€ TODO.todo
  â”œâ”€â”€ index.html
  â”œâ”€â”€ package.json
  â”œâ”€â”€ src/
  â”‚   â”œâ”€â”€ components/
  â”‚   â”‚   â”œâ”€â”€ containers/
  â”‚   â”‚   â”‚   â””â”€â”€ root.js #1
  â”‚   â”‚   â”œâ”€â”€ displayItems.js #2
  â”‚   â”‚   â”œâ”€â”€ hello.js #3
  â”‚   â”‚   â”œâ”€â”€ page2.js #4
  â”‚   â”‚   â””â”€â”€ styled/
  â”‚   â”‚       â”œâ”€â”€ elements/
  â”‚   â”‚       â”‚   â”œâ”€â”€ listwrapper.js #5
  â”‚   â”‚       â”‚   â”œâ”€â”€ navwrapper.js #6
  â”‚   â”‚       â”‚   â”œâ”€â”€ routerwrapper.js #7
  â”‚   â”‚       â”‚   â””â”€â”€ styledlink.js #8
  â”‚   â”‚       â””â”€â”€ index.js #9
  â”‚   â”œâ”€â”€ main.js #10
  â”‚   â”œâ”€â”€ routes/
  â”‚   â”‚   â””â”€â”€ index.js #11
  â”‚   â””â”€â”€ store/
  â”‚       â””â”€â”€ listItems.js #12
  â”œâ”€â”€ tslint.json
  â””â”€â”€ yarn.lock

Twelve JavaScript files for a boilerplate; we're talking about a glorified 'Hello World'. Are these large files? Not at all. Take the files found under src/components/styled/elements/ (full size):

All of the files are under 25 lines of code. In fact, every file inside the src/ folder comes in under 50 lines. I didn't do this for the sake of line count, however. That's a beneficial side-effect of writing modular code. I split my code this way because it gives me a codebase that's easier to maintain, easier to read, easier to navigate, and easier to debug. If I need to change the way my links appear, I know exactly where I need to go to make that change, and I know that once the change is made it will reflect anywhere that a link is created. The folder structure, while probably not all that visually appealing, is nice when programming because it's logical and organized; a styled link element is found under styled/elements/styledlink. If there's an error or a bug (which there definitely will be), it's easy to trace the problem back to one file/module because they're split up with the intention of giving each module one job. If something breaks, it's probably because I didn't tell someone how to do their job correctly, and it's usually easy to tell where the error is originating from. Once the error is addressed at the module level, I know it's going to be fixed anywhere else that code was reused.

Webpack as a Solution

So how do we get this loaded into the browser without dealing with <script> tag shenanigans? Webpack! Webpack will crawl through our app starting from the application root, or the initial kick-off point (src/main.js), following any import statements until it has a complete dependency graph of the application. Once it has that graph, it will create a bundled file (or files, depending on how you configure Webpack) which can be then be loaded into the browser from inside index.html. VoilÃ ! In it's simplest use case, that's what Webpack does. It takes a bunch of JavaScript files and puts them together into one (or a few) files that are more manageable to work with when loading into the browser, while allowing you to maintain the modularity and separation that you like in your codebase.

"Wait a minute, guy. I've seen people use Webpack for CSS, pictures, videos...everything, and you're telling me it only does JS?" Yes! Out of the box, that's what Webpack is capable of understanding. However, at the beginning of my first post I mentioned that Webpack is much more than just a module bundler. With the right configuration settings, plugins, and loaders (more on this later), Webpack can be extended to understand most filetypes that front-end developers come across in order to bundle (and optimize) ALL of your application assets. In most cases, my build process is entirely managed by Webpack & NPM scripts.

A Basic Configuration

Pre-requisites:

Node
NPM/Yarn - Installing dependencies, running scripts
Git - Branch, clone, commit
Patience - I may be too wordy for my own good sometimes

Example code for this section can be found at: github.com/nitishdayal/webpack-stages-example

The rest of this post assumes you'll be following along by cloning the repo containing the example code. The repo is split into multiple branches that correspond with the upcoming sections.

Initial file layout & directory structure:

 â”œâ”€â”€ index.html
 â”œâ”€â”€ package-lock.json
 â”œâ”€â”€ package.json
 â”œâ”€â”€ src
 â”‚   â”œâ”€â”€ app
 â”‚   â”‚   â””â”€â”€ sayHello.js
 â”‚   â””â”€â”€ index.js

The example provided has a few files worth noting:

index.html
src/app/sayHello.js
src/index.js

Let's break down what's happening in the example:

index.html is an HTML document with two key items:
- The div HTMLElement with the id root
- The script tag loading a file ./build/bundle.js
src/app/sayHello.js exports two items.
- An anonymous function which takes one argument and returns a window alert with the message 'Hello ' + the provided argument as the default export.
- A constant donut with a string value as a named export.
src/index.js is the file that interacts with the document.
- The default export from src/app/sayHello.js is imported to src/index.js and is referred to as Hello.
- Two variables are declared & defined, name with a reference to a string value and root referencing the div HTMLElement w/ an ID of 'root'.
- The Hello function (default export from src/app/sayHello.js) is called, and is provided the previously declared name variable.
- The text content of the div HTMLElement referenced by root is updated to 'Helllloooo ' + name +'!'

Step 1

Branch: Master

First, we'll need to install Webpack. If you're using the example code, run npm install/yarn from your command line. If you're creating your own project to follow along with, run npm install webpack -D/yarn add webpack -D. The -D flag will save Webpack as a developer dependency (a dependency we use when making our application, but not something that the core functionality of the application needs).

NOTE: Sometimes I run Webpack from the command line. I have Webpack installed globally in order to do this. If you want this option as well, run npm install --global webpack/yarn global add webpack from the command line and restart your terminal. To check if Webpack is installed correctly, run webpack --version from the command line.

Once Webpack is installed, update the "scripts" section of the package.json file:

"scripts" {
    "build:" "webpack"
},

We've added a script, npm run build/yarn build, which can be called from the command line. This script will call on Webpack (which was installed as a developer dependency via npm install webpack -D/yarn add webpack -D). From the command line, run npm run build/yarn build.

Error message! Woo!

No configuration file found and no output filename configured via CLI option.
A configuration file could be named 'webpack.config.js' in the current directory.
Use --help to display the CLI options.

As far as error messages go, this one is pretty friendly. Webpack can be run in many ways, two of which are mentioned in this error message; the command line interface (CLI) or a configuration file. We'll be using a mixture of these two options by the end, but for now let's focus on the configuration file. The error message mentions that a configuration file could be named webpack.config.js; you can name your configuration file whatever you want to. You can name it chicken.cat.js. As long as that file exports a valid configuration object, just point Webpack in the right direction by using the --config flag. Example (from command line or as package.json script): webpack --config chicken.cat.js. If, however, you name your file webpack.config.js, Webpack will find it without the need for the --config flag. With great power comes great responsibility, etc.

We know that Webpack failed because we didn't configure it properly, so let's create a configuration file.

Step 2

Branch: init

There's a new file in this branch named webpack.config.js:

module.exports = env => ({
  entry: "./src/index.js",
  output: { filename: "./build/bundle.js" },
  resolve: { extensions: [".js"] }
});

...wat

Yeah, me too. Let's break this down! First, let's rewrite this without the arrow function and so the output and resolve objects are split into multiple lines:

module.exports = function(env){
  return {
    entry: "./src/index.js",
    output: {
      filename: "./build/bundle.js"
    },
    resolve: {
      extensions: [".js"]
    }
  }
};

Currently we're not doing anything with this 'env' argument, but we might use it later. Exporting a function is an option, but at the end of the day all Webpack cares about is getting a JavaScript object with the key/value pairs that Webpack knows. In which case this example could be further simplified to:

// Oh hey look! Somewhere in that mess was a good ol' JavaScript object. The kind 
// you can 'sit down and have a beer with'.
module.exports = {
    entry: "./src/index.js",
    output: {
        filename: "./build/bundle.js"
    },
    resolve: {
        extensions: [".js"]
    }
};

This object has 3 keys: entry, output, and resolve. Entry defines the entry point of our application; in our case, it's the index.js file. This is the file that first interacts with the HTML document and kicks off any communication between the other JS files in the application. Output is an object which contains options for configuring how the application's files should be bundled and outputted. In our case, we want our application to be bundled into a single file, bundle.js, which should be placed inside a folder named build/. Resolve is an object with an array extensions that has a single value, '.js'. This tells Webpack that if it comes across any import statements that don't specify the extension of the file that the import statement is targeting, assume that it's a .js file. For example, if Webpack sees this:

import Hello from './app/sayHello';

Given the configuration provided, it would know to treat this as:

import Hello from './app/sayHello.js';

To recap: The file webpack.config.js exports a function which returns an object (that's what the whole module.exports = env => ({ /*...Webpack config here...*/ }) thing is). The object that is returned consists of key/value pairs which is used to configure Webpack so that it can parse through our application and create a bundle. Currently, we're providing Webpack with the following:

Where our application starts (entry)
Where we want our bundle to go and how we want it to look (output.filename)
How Webpack should treat imports that don't specify file extension (resolve.extensions)

Now, if we call npm run build/yarn build from the command line, Webpack should be able to do it's thing:

$ npm run build
> example@1.0.0 build /Projects/dev_to/webpack_configs/example
> webpack

Hash: fa50a3f0718429500fd8
Version: webpack 2.5.1
Time: 80ms
            Asset     Size  Chunks             Chunk Names
./build/bundle.js  3.78 kB       0  [emitted]  main
   [0] ./src/app/sayHello.js 286 bytes {0} [built]
   [1] ./src/index.js 426 bytes {0} [built]

There should now be a new folder build/ with a file bundle.js. According to the output from calling npm run build, this file consists of ./src/app/sayHello.js and ./src/index.js. If we look at this file and look at lines 73-90 we see:

"use strict";
/* harmony default export */ __webpack_exports__["a"] = (name => alert(`Hello ${name}`));

const donut = "I WANT YOUR DONUTS";
/* unused harmony export donut */


/**
 * Same code, ES5(-ish) style:
 * 
 * var donut = 'I WANT YOUR DONUTS';
 * 
 * module.exports = function(name) {
 *    return alert('Hello ' + name);
 * };
 * exports.donut = donut;
 * 
 */

That's ./src/app/sayHello.js, and would you look at that, Webpack knew that even though const donut was exported from the file, it wasn't used anywhere in our application, so Webpack marked it with /* unused harmony export donut */. Neat! It did some (read: a lot) of other stuff too, like changing the export syntax into...something else entirely. ./src/index.js can be seen in lines 97-111. This time, anywhere that a piece of code from ./src/app/sayHello.js is used, it's been swapped out for something else.

"use strict";
Object.defineProperty(__webpack_exports__, "__esModule", { value: true });
/* harmony import */ var __WEBPACK_IMPORTED_MODULE_0__app_sayHello__ = __webpack_require__(0);

// Import whatever the default export is from /app/sayHello
// and refer to it in this file as 'Hello'

const name = "Nitish";
// Reference to the <div id="root"> element in
const root = document.getElementById("root");

// Call the function that was imported from /app/sayHello, passing in
// `const name` that was created on line 5.
__webpack_require__.i(__WEBPACK_IMPORTED_MODULE_0__app_sayHello__["a" /* default */])(name);
root.textContent = `Helllloooo ${name}!`;

Going over everything that is happening in the bundle is best saved for another post; the intention of looking at this file to prove that, yes, Webpack did indeed go through our code and place it all into one file.

If we remember, the index.html document had a <script> tag which referenced this bundled JS file. Open index.html in your browser to be greeted by an alert and a sentence inside a div! Congratulations, you've used Webpack to create a bundle!

EDIT: Part 3 is finally up!

Stages of Learning Webpack

Nitish Dayal — Mon, 15 May 2017 22:26:29 +0000

DISCLAIMER: This post doesn't provide any valuable information. It's mostly just for fun, and to share the struggles and 'Aha!' moments that some of us might have mutually experienced.

Purpose of this post:

Webpack is worth learning. It is so much more than a module bundler.
A few months back, I wrote a post on here about my first experience with configuring TypeScript + React and Webpack. That configuration was, apparently, terrible. So terrible that I decided to delete that post because I was giving out a lot of misinformation (also I looked really stupid ðŸ¤·ðŸ¾”â™‚ï¸). I've learned a bit more about Webpack since then and would like to take another crack at that post. And, preferably, do it right. But first, I wanted to share a summary of my Webpack learning experience (because light humor and humility are good things).

Stages of Learning Webpack (from Jan-April):

I write (copy/paste) my first config. I have no idea what the hell I'm doing, but according to the Twitter HypeTrainâ„¢, I need Webpack. I run Webpack and end up with a 2MB bundle for a 'Hello World', which is now broken with error messages I'm positive are written in some alien language. Baffled, I start changing things, still no clue what the hell I'm doing. Just...panicked, trying to figure out why this thing that was supposed to make my app smaller just made it like 500x bigger. How did I manage to break this so badly? I headdesk the night away.
Aha! I did a thing! My app is working and WAY smaller! 200kb?! Daaaaaaaaang boi! I'm stoked! I still have no idea what the hell is going on, but I'm so excited I decide to make it into a starter/boilerplate and write a blog about it. It's up for two months. For whatever reason, no one bothers to let me know...hey, you're doing it wrong and it should be WAY smaller. I keep headdesking away.
I now have a basic idea of what the hell I'm doing. Webpack is a thing. It takes an object with some key/value stuff. It uses the key/value stuff to go through my app and, based on what keys/values are provided, creates a bundled version of my app. It might be big; it might be small. The point is that it's bundled. Anything after that is my call. 'My call' has graduated from randomly changing things and hoping for the best to docs > find the thing > install the thing, if necessary > use the thing. Apparently this object can actually be a function that returns an object? Whatever. Embarrassed that I ever wrote/published that original article, I find it and delete it immediately. I want a redo, and I want to do it right. I headdesk on.
Webpack docs and I are tight. I know where to go to find what I need, but I've been breaking/remaking these configs for so many months, at this point the docs are a fallback. Webpack is, officially, the homie. I can probably set up a dev environment with separate webpack configs for dev/prod/staging in a short period of time. I have opinions on what loaders and plugins to use when/why. I've had conversations about separate vs. single webpack config files; conversations which generally ended with either party giving the ol' eye-roll and 'agree-to-disagree' spiel. Opinions, right? Am I a pro? By no means. Do I have a general understanding of the tool, the problems it attempts to solve, the benefits I can potentially gain from it, and why it is that I apparently needed this thing? Absolutely.

I'll have another post tomorrow which details:

What is Webpack? Do I really need it? (spoiler: probably not, but you might benefit from it)
The changes I've made to the boilerplate since the last post, and why
Recommendations & tips for navigating the documentation
Templates for a few of the more typical front-end development setups I've come across

If you see opportunities for improvements in the boilerplate configuration, please contact me/submit a PR. Thanks for reading! âœŒðŸ¾

EDIT: Part 2 is up!

Nitish Dayal

Nitish Dayal — Tue, 25 Apr 2017 10:58:14 +0000

Tunes and tech. I'm...very boring.

Twitter: @nitish_dayal

Employment Status: Taken â¤ï¸

Programming Languages I'm familiar with: JavaScript(ES5 and on, TypeScript, Flow), Swift (3), Python(2.7,3)

Studying: Functional programming, design patterns, type systems.

Work with me on something! Github