In this tutorial, you’ll learn the following:

• Introduction to Composer.
• Minimum stability in Composer.
• Levels of stability, and the recommended version for production code.

One of the benefits of using a dependency tool is that it makes it easy to declare the key-value pair of packages you need for your project. This way, you can install dependencies via the composer install command or update them via the composer update command in the terminal.

Introduction to Composer

In Laravel, the composer.json is a JSON file located at the root of the project directory. It contains sample configurations used for dependency management, such as the project name, type (optional), description (optional), and the list of required packages.

These packages are represented using key-value pairs (name and version to be installed). Additionally, the composer.json file includes some required packages for the development environment which can be added as part of the configuration setup.

Here's what a composer.json file looks like:

{
    "name": "laravel/laravel",    
    "type": "project",    
    "description": "The Laravel Framework.",    
    "keywords": [        
        "framework",        
        "laravel"    
    ],    
    "license": "MIT",    
    "require": {        
       "php": "^8.1",        
       "laravel/framework": "^10.0",    
    },    
    "require-dev": {    
         .    
         .     
    },    
    "config": {    
         .    
         .    
    },    
    "minimum-stability": "dev"| "alpha"| "beta"| "RC"|"stable", //stable
}

What is Minimum Stability?

In Composer, the “minimum-stability” configuration specifies the minimum stability level for all installed packages.

Packages to be installed or updated will use the minimum-stability value to determine version limitations during dependency resolution.

Levels of Stability

The following are the different stability levels:

• dev: This is the least stable version, and should never be used in production. It often includes packages under active development that may contain bugs or breaking changes and may still undergo significant modifications. It is only recommended for local development purposes.
• alpha: It's a version also undergoing development but in a more stable state. It usually contains fewer breaking changes and features nearing final completion or awaiting a beta release. However, it is also not highly recommended for production environments.
• beta: This version is currently being tested, and minor bugs, when noticed, will need to be fixed. However, it is more stable than the alpha and dev versions, but it's still not recommended for production purposes.
• RC: The RC (Release Candidate) is a version pending official release. It's the closest to being stable, but the version requires community testing and feedback prior to the final release. Undiscovered bugs can also be identified during this phase, so it's best practice not to use it for production purposes.
• stable: This is the required level for production purposes. It includes all packages that have gone through significant changes, bug fixes, community testing, feedback, and is now ready to use.

In your composer.json, you can specify the minimum stability by doing the following:

{
    "minimum-stability": "stable"
}

Conclusion

In this article, you have learned about Composer, the composer.json file, minimum stability, and, most importantly, the levels of stability offered by Composer.

For your application, you should carefully choose the stability level that satisfies your production needs, while keeping security and downtime issues in mind. Remember, your application should only depend on stable and reliable packages.

I hope you now have a better understanding of minimum stability.

Keep learning, and Happy Coding!

You can find me on LinkedIn and Twitter.

As a developer, how often have you seen a repository with packages that are out of date?

New package updates generally include new features, performance improvements, and security fixes. But keeping track of all outdated dependencies in your project can be really boring and a time consuming task, especially if you have lots of them.

So to do this sort of housekeeping, I tried out Dependabot.

How Dependabot Works

Dependabot goes through the dependency files of your project. For instance, it searches your package.json or pom.xml files and inspects for any outdated or insecure dependencies. If it finds any, it opens individual pull requests to update each one of them.

This tool is natively integrated with GitHub. But recently, I had to solve this problem of updating dependencies for a project running in Azure DevOps. So I decided to find a workaround to integrate Dependabot with Azure Pipelines. In this blog post, I will share my solution.

If you go to Azure DevOps Extension Marketplace and search for "Dependabot", you will find an extension by Tingle Software. Using this extension we can easily integrate Dependabot with our repos in Azure DevOps.

You can check if you have this extension in your "Organization Settings" in Azure DevOps. If not, make sure you have it installed before proceeding.

Installed Extensions - Azure DevOps

How to Create the Azure Pipeline

Let's now create start with creating a new YAML file for your azure pipeline:

trigger: none

stages:
  - stage: CheckDependencies
    displayName: 'Check Dependencies'
    jobs:
      - job: Dependabot
        displayName: 'Run Dependabot'
        pool:
          vmImage: 'ubuntu-latest'
        steps:
          - task: dependabot@1
            displayName: 'Run Dependabot'
            inputs:
              packageManager: 'npm'
              targetBranch: 'develop'
              openPullRequestsLimit: 10

In the task parameters, I have specified three params:

1. packageManager: It specifies the type of packages to check for dependency upgrades. Examples: nuget, maven, gradle, npm, and so on.
2. targetBranch: It is an optional parameter that defines the branch to be targeted when creating pull requests. When not specified, Dependabot will pick the default branch of the repository.
3. openPullRequestsLimit: This is again an optional parameter that specifies the maximum number of open pull requests to have at any one time. By default, it opens 5 pull requests at a time.

You can go through all the Task Parameters that the extension supports to tweak your implementation. Now just simply configure this YAML file with a new azure pipeline and then you're ready to run it.

Pipeline Configuration - Azure DevOps

The next step is to give your repository's Project Collection Build Service access so that Dependabot can create the pull request to your project's repositories.

For that, go to your project settings. Here, you click on the repositories and search for the repo where you have integrated the pipeline.

After you have selected that, click on the security tab and search for project collection build service. You have to allow the following access to it:

• Contribute
• Contribute to pull request
• Create Branch
• Create Tag
• Force Push

Access to raise PR in Repo

With this, you're completely ready to run the pipeline. Once you do it, you'll start receiving pull requests in your repository with the updated packages.

PR raised by Dependabot

How to Schedule the Pipeline

Up to this point, you've had to manually trigger the pipeline to run. To make it run automatically, you can configure schedules for your pipelines. This will trigger your pipeline to start based on a schedule.

Use the following syntax and add it to the very top of your YAML file:

schedules:
- cron: string
  displayName: string
  branches:
    include: [ string ]
  always: boolean

The branches’ include parameter specifies which branches the schedule applies to.

The always parameter specifies whether to "always" run the pipeline or only if there have been any source code changes since the last successful scheduled run. The default is false.

For this case, you set its value to true as Dependabot updates are independent of any code changes.

The time zone for cron schedules is UTC and cron syntax is as follows:

mm HH DD MM DW
 \  \  \  \  \__ Days of week
  \  \  \  \____ Months
   \  \  \______ Days
    \  \________ Hours
     \__________ Minutes

So if you want to run your pipeline every week on Sunday at 12pm UTC, you would need to write - cron: "0 12 * * 0" (update the cron to suit your needs).

This is how your final YAML should look like after adding a schedule:

schedules:
  - cron: "0 12 * * 0"
    displayName: Weekly Dependency Updates
    branches:
      include:
      - develop
    always: true

trigger: none

stages:
  - stage: CheckDependencies
    displayName: 'Check Dependencies'
    jobs:
      - job: Dependabot
        displayName: 'Run Dependabot'
        pool:
          vmImage: 'ubuntu-latest'
        steps:
          - task: dependabot@1
            displayName: 'Run Dependabot'
            inputs:
              packageManager: 'npm'
              targetBranch: 'develop'
              openPullRequestsLimit: 10

This pipeline does the following for you:

It runs on a weekly basis (Sunday 12pm UTC in this case) and looks for any outdated or insecure dependency. If it finds any, it opens pull requests to update each one of them individually.

Hopefully, this will help you to keep your project dependencies up to date in Azure DevOps!

Wrapping Up

With this, we come to the end of the article. My DMs are always open if you want to discuss further on any tech topic or if you've got any questions, suggestions, or feedback in general:

• Twitter
• LinkedIn
• GitHub
• Blog

Happy learning! 💻 😄

Releasing modern software might seem daunting and complicated. In this article, I'll expand on the concepts involved in the process, from managing dependencies to building in the cloud.

Articles and tutorials usually cover a specific tool and dive right into it before laying down the foundational knowledge. In this article, I'll provide that foundation by introducing the concepts that go into these tools.

The topics I'll cover include dependency management (and what dependencies really are!), build systems, and continuous integration systems with a little bit of icing on the cake. Having this background will help set you up for what's to come.

What are Libraries?

Say you're chipping away dutifully at your tasks. You create a collection of utilities that make your job easier. You're then assigned to a different project in which you need the same utilities, and copy them over. Congratulations, you just created a library and used it across two projects! 😁

Libraries are collections of pre-written code that developers use to optimise tasks. They boost our productivity by abstracting away the boring and repetitive stuff. Numpy, Matplotlib, Lodash, jQuery, and React are all examples of popular, open-source libraries.

You've probably noticed that each of these libraries (or any other library) has a version number. It's usually constructed as a few numeric fields separated by periods: v1.0.0 or just 1.0.0. These numbers are not random! There are many schemes for defining a version of a product.

Some products use the build number generated by a compiler or CI/CD tool (we'll look into these in a minute). Other products use the date of the build instead of the build number. Others use a build hash.

The most prominent versioning scheme is called Semantic Versioning. It's what most (if not all) code libraries use.

What is Semantic Versioning (Semver)?

Semantic versioning is a versioning scheme in which you have 3 fields, each separated by a dot. For now, we'll call the first field (on the left side) Major, the one in the middle Minor, and the last one Patch. It looks exactly like this, with some derivations: Major.Minor.Patch.

Per the Semver standard, all fields must increment only. You can't decrement any of them. When a parent version is incremented, all children are reset. So incrementing Major resets Minor and Patch to 0.

The patch version

The Patch version is the most frequently changing number. When this number is incremented, it indicates a change that doesn't add new features or break existing functionality. These may be security fixes, performance optimisations, bug fixes, and so on.

Changes to the Patch version are always two-way compatible, as long as parent versions are the same. Code written on v1.0.1 will work on v1.0.0 and v1.0.2.

The minor version

The Minor version is the second most frequently changing number. A change to this number indicates a feature update that doesn't break existing functionality.

Changes to the Minor version are always forward compatible, as long as the Major version is the same.

Code written with v1.1.0 will work with v1.2.0 but may not work with v1.0.0, as you may be using features added in the more recent version.

The major version

The Major version is the highest priority and the most "dangerous" field of the three. When this number is incremented, it indicates breaking changes. These are usually API/interface changes and/or entity renaming and removal.

A new Major version is not meant to be compatible with any other Major version, so don't expect v1.0.0 to work with v2.0.0 or vice versa. Your code may compile after an upgrade, but that's just pure luck.

There are cases in which library authors break underlying logic without affecting the public API you use, so it doesn't break your code. But these are exceptions.

Python 2 and Python 3 are examples of breaking changes. Python 2 print statements don't work on the Python 3 interpreter, and vice versa. Some of it may work, like for loops and other basic structs, but that's about it.

It's recommended that you stay up to date as much as possible with the Patch version. If you need the new features, upgrade your Minor version. A change in Major indicates enormous changes. So be careful when you're upgrading.

There's usually a migration guide with each major release that you should follow. You can read more about Semver in the official documentation.

So... how do we install and use external libraries written by other people in the first place?

How to Manage Your Project's Dependencies

In the past, the best that we could do was to actually copy the source code of the libraries we were using into our projects. We applied changes to the library's code, fixed bugs before they were released, and had control over the code.

But this practice, commonly referred to as vendoring, has fallen out of favour for multiple reasons.

If you had applied changes and a new version was released, you had to re-apply all those changes again. It's a manual process that needs to happen every time you update or download a library. It's cumbersome, takes a lot of time, and may break extra functionality that you added.

This quickly gets out of hand when increasing the project's complexity and scale, which leaves us with the better option: Dependency Managers.

What is a Dependency Manager?

A dependency is a library or utility that your project needs to work. Simply put, if Program A requires Program B to compile and/or run, Program A is dependent on Program B. A program can depend on multiple other programs.

A dependency manager is a tool that automatically keeps track of a project's dependencies. It allows you to run simple commands in the terminal to install, update, and remove dependencies. NPM, Yarn, Composer, Gradle, and Bundler are all examples of dependency managers.

Don't confuse these with Package Managers, as those are tools that manage system-wide packages. apt-get, yum, Homebrew, and Chocolatey are package managers.

Some package managers can manage system-wide packages and project dependencies. NPM and Yarn are examples of this.

How does a dependency manager work?

A dependency manager uses two main files: a manifest and a lock file.

The manifest is a list of your project's direct dependencies. It lists the dependencies that you directly specified when installing something. So when you run npm install jsdom, it adds the jsdom package to the list of dependencies in the project's manifest.

But the manifest is not enough. A dependency may have dependencies, and those may have dependencies as well, and so on, forming a dependency graph. A manifest includes only direct dependencies.

Therefore, when you run npm install jsdom, the manifest will only list jsdom despite jsdom having other dependencies of its own. So, how do dependency managers keep track of the whole dependency graph?

What are Lock Files?

A lock file is a log that lists all the project's dependencies. This includes direct dependencies (listed in the manifest) and the whole dependency graph. It lists every dependency with a specific version, the repository it was fetched from, and other details.

This image shows a comparison between the dependency graph (listed in the lock file) and the direct dependency list (listed in the manifest) of jsdom, a JavaScript implementation of many web standards for testing.

Okay, we know the exact dependency graph, but so what? So everything! We often have multiple developers working on the same project. A dependency manager may install different versions of a library if multiple developers install the project's dependencies using only the manifest.

A lock file locks each dependency in the graph to a specific version, allowing us to have reproducible builds on different machines. This means that every time someone runs npm install, the code is guaranteed to work. This also makes it easier to report bugs by including a lock file in the report.

Lock files also allow dependency managers to reuse cached packages instead of downloading the latest version every time you build your project.

So we've learned what libraries, semantic versioning, and dependency managers are. Now it's time to build our project.

What are Build Systems?

Every build process is a build system in one way or another. A build system is a set of transformations that transform a source into an artifact. It may be a simple command that starts up a compiler, a script to generate pdf from text files, or even a GUI solution that builds your project and generates a binary.

A build system generally consists of 3 components:

• Targets
• Dependencies
• Rules

A target is the desired output. If you want a binary called "test.exe", then your target is just that. Dependencies are project dependencies and may include environment utilities like having the C++ compiler installed, npm available, and so on. Rules define how you go from source to target. They may also be the commands used.

A build system may be configured to test your app, generate coverage reports, and lint sources before building as part of its rules. But a build system is manual and local by default. You have to start it up yourself, and it only produces an output on your local machine.

So... what if you want multiple developers to be able to release versions of your app incrementally? This is where CI/CD comes in!

Continuous Integration Systems

In short, Continuous Integration (CI) is a paradigm in which you continuously validate changes to a product. A CI system automatically builds and tests every change to avoid problems that may arise when waiting for a release.

Continuous Delivery (CD) is the practice of automating the release process. Major releases are automatically deployed to staging and production, providing an automated release process.

Continuous Deployment (CD) is a step-up from Continuous Delivery. It's the practice of automatically deploying every change if it passes all stages of your production pipeline, without waiting for any explicit approval. This practice emphasizes test automation and user feedback, often leading to multiple software updates a month, week, or even a day!

It's a broad concept that you can read more about in this article. For now, we'll refer to the systems that host these practices collectively as Continuous Integration Systems.

A continuous integration system (CI for short) is a build system in the cloud that activates a project's build system on demand and automatically. It's a keystone in the success of agile teams.

CIs consist of three main components:

• Triggers
• Actions
• Recipes

Triggers are events that the CI listens for to start the build system. These events may be a commit on main branch, a pull request for feature previews, or one of many others. Each platform supports several events.

Actions are commands and scripts that are started upon triggers. You may say: "Build project upon commit on main branch" in the system's language.

Recipes are configurations that specify triggers and actions, environment setup, environment variables, build systems, and system dependencies. They're the system's language.

Note that you can have multiple build systems on the same CI, each with different targets and rules.

TravisCI, Jenkins, CircleCI, GitHub Actions, and GitLab CI/CD are examples of CIs we come across every day. The following is an example GitHub Actions recipe to release new versions of a program and send them to GitHub Releases:

on:
  push:
    branches:
      - main // will start the CI when a push to branch main is made

jobs:
  release_linux:
    runs-on: ubuntu-latest // must be run on ubuntu@latest

    steps:
      - name: check out git repository
        uses: actions/checkout@v1

      - name: install Node.js, npm and yarn // required env tools
        uses: actions/setup-node@v1

      - name: install deb packages // required env dependencies
        run: sudo apt-get install fakeroot dpkg rpm

      - name: build and release app
        uses: kl13nt/action-electron-forge@master
        with:
          // release to github releases after successful build
          release: ${{ startsWith(github.ref, 'refs/tags/v') }}

I've omitted a ton of config stuff in there, but you get the idea. I specified the trigger as a commit on "main" branch and the actions to clone the project's repository, install NodeJS, npm, yarn, and other environment dependencies.

The build stage will run an npm-scripts build system which will lint and test the code before building. The CI will then send the output binaries to the project's GitHub Releases page.

A lock file also comes into play when pushing to a CI as well! If the CI installs different versions of dependencies than the ones you have locally, it may fail. This is why a lock file is as necessary for CIs as it's for developers, so you can rest assured that the code that worked on your machine will work the same way on the CI.

Conclusion

If you've made it this far, I really hope this was an inspiring (and gentle!) learning experience. You can find more of my content on my website. Thanks for reading!

Further Reading

• What is Package Lock
• The Missing Semester of Your CS Education - Metaprogramming
• The Simple Magic of Package Manifests and Lockfiles

There are multiple ways to get third party code included and updated. And I read something recently which has easily become my favourite way of doing this, so I had to share it.

This method is to Always Shim Your Abstractions.

To properly break down what this means, let's define each word before we talk about the bigger idea that it encompasses.

Abstractions

Developers often use abstractions in code to simplify a system.

Abstractions are a way of hiding complicated code inside something, and they normally provide an easy interface to use it.

So for example, let's say we have some complex code that ends up doing lots of very specific math. We can wrap all that logic up in a function and provide a really easy interface where you just pass in your number and the function will do the work.

We are essentially not forcing the person who uses our code to worry about the implementation details. They can just call the function and they'll get their answer back – they don't have to worry about what the function is doing "under the hood".

That's the strength of abstracting details away in your code.

You can abstract things away in a multitude of data structures or code architecture. And you can abstract implementation details inside a prototype, class, function or more.

If you had to understand every single line of code in a big codebase (let's say a 2 million line codebase) you'd never be able to start coding.

You can create a reusable, simple to understand, and easily changeable codebase by abstracting away certain details into the correct modules/separating out your code.

How code abstraction works

An example of abstracting away logic would be: imagine if you were creating a machine to make coffee for your users. There could be two approaches:

How to Create it With Abstraction

• Have a button with the title "Make coffee"

How to Create it Without Abstraction

• Have a button with the title "Boil the water"
• Have a button with the title "Add the cold water to the kettle"
• Have a button with the title "Add 1 spoon of ground coffee to a clean cup"
• Have a button with the title "Clean any dirty cups"
• And all the other buttons

Can you see how when we use abstraction we don't expect the user to know how the machine makes coffee? But in the machine without abstraction, the user has to know in which order to press each button which forces the user to understand how the coffee is made.

There's one definition we need to cover before we can move on and understand the concept I introduced at the beginning (always shim your abstractions), and that's shimming.

Shimming

Shimming is the act of putting something in front of something else to intercept data being passed.

Let's look at an example of how it works.

Let's say a bank has a really old API that doesn't accept JSON due to some technical legacy defect. Instead it can only accept XML. We'll call this LegacyAPI.

But a high percentage of developers who want to hit this bank API want to send JSON. The bank refuses to change LegacyAPI as it's too risky and might break the API. So much of their system depends on it, and they can't risk doing lots of new development and taking huge parts of their system down if they make a mistake.

They could always shim LegacyAPI if they don't want to do new development on it.

They could do this by creating an API that sits "in front" of LegacyAPI. We'll call it NewAPI.

The wording "in front" just means the order of who first deals with the network request. By "in front" we just mean NewAPI will be the first to receive the network requests.

You would tell the developers they can now hit NewAPI with JSON as they wanted, and NewAPI will turn the JSON into XML for the LegacyAPI and both parties can be satisfied.

The bank can now expand their services (they can accept JSON, for example) via the NewAPI without changing their old legacy API that they were wary of changing.

This is just one example of shimming. And just to review, it is essentially adding something in front of something else to act like a man in the middle to pass data to something else.

A diagram of how NewAPI intercepts LegacyAPI network requests.

Hopefully you have a good understanding of what shimming is and what abstractions are. Let's bring both definitions together to define what we mean by Always Shim Your Abstractions.

Why You Should Always Shim Your Abstractions

The problem

Whenever we need to manage our dependencies, we want to make sure we stop the third party code "leaking" all over our main code.

By "leaking", I mean that the dependency code is imported multiple times to different places that need it in your code.

If you let a dependency "invade" your source code, you are becoming increasingly tightly coupled to it each time you import it.

This can (at times!) mean you will be forced to code in the direction the library choses as you are tightly coupled to it. This may end up leading to significant cognitive overhead as you are increasingly trying to make this library work in your code, but it isn't in keeping with the rest of your architectural decisions.

This can make any refactoring you need to do take much longer than if you isolated it. For example, if the dependency changes, what arguments would it need to accept to create an object in the dependency?

In addition to it being difficult to keep your build working well with the dependency, if it no longer suits your needs or you find a better library to replace it, your refactor becomes much more difficult to actually get rid of it.

The solution

To try and stop all the above from happening, firstly let's put any dependencies we need into their own modules where they're only referenced once in your codebase.

This is in essence our shim.

Whenever you need the third party dependency, you just have to import the wrapper module we put around it, to act like a "man in the middle", to provide a level before we call into our third-party dependency.

This shim module also allows us to make our dependencies abstractions. The developers who need to use our third party dependencies can just use an abstraction instead (you'll probably end up just wrapping it in a function or simple class). You'll default the arguments to sensible defaults and try to remove as much of the nitty gritty implementation details as you can.

Anywhere else that needs this dependency will just load your module and then that module can be injected where necessary.

Why? One big reason we already discussed is that it stops your dependencies and your code from being too tightly coupled.

This works when you only have it in only one module. As long as everyone that is loading your module respects an interface/data contract for that module, everywhere else "gets it for free". Then you only have to change one module for lots of other places to get access to something.

This then allows us to make changes far more easily, and keeps a clean separation of concerns in the code.

We have only spoken here about one dependency – but you can see how much worse this may get if, for example, you are relying on 25 other custom libraries and you need to understand how they work. This would generally be a pretty fragile codebase, and would be a code smell.

HTTP dependency example

Let's look at an example of a dependency you might use that makes a simple HTTP client.

It's a basic dependency that lets you hit endpoints and pass JSON etc as data.

Let's imagine then we currently are using Fetch in Node and we want to use Axios (another HTTP client we want to now switch to). We've decided to drop Fetch and switch to Axios because our application is growing in complexity and we have found that Axios now fits our use-cases better.

If Fetch has leaked all over our codebase, then our refactor to remove it is going to be much harder than it needs to be.

Rather than just go to our one module where we shimmed the function call, we now have to go to every place where we use it. This creates a domino effect in the source code that inevitably will occur from changing something in multiple places.

// You're now going to have to find any place you imported fetch
// Any place you alias'd it
// And deal with any source code failures wrapping around where you have used it once it's removed
// Which might be more complex than just simply searching for
const fetch = require('node-fetch');

We can improve this by wrapping the dependency into an appropriate shimmed abstraction and isolating its usage to one place.

You also get a win when onboarding people. They'll be able to see abstractions called API or DataStore which become clear signposts as to what your classes do (rather than a library that a developer may not be familiar with).

// In your abstractions, you get the power to give it a descriptive
// name, if the current name isn't clear in your code too, maybe like:

var Money = require('dinero')

This won't be an issue for well known dependencies like Express or Lodash maybe. But I don't have a perfect memory of every NPM package and what they do.

When you've properly shimmed it, it doesn't even matter to the developers using your shim if you are using Fetch or Axios "under the hood". They'll never know the difference if you change it, as long as you are sensible with the shim.

Conclusion

I hope this gave a good overview of the benefits of shimming, and how it helps you maintain your dependencies.

This whole article was influenced by the writings of Sarah Dayan, found here, and shared with her consent.

I share my writing on Twitter if you enjoyed this article and want to see more.

There is a rather progressive sect of the software development world called the open source community.

This community believes that most people would be a lot happier and get a lot more work done if they stopped building things that someone else has already built and offered up for free use. They want you to take their stuff.

Besides existing without you having to lift a finger, open source tools and software have some distinct advantages. Especially in the case of well-established projects, it’s highly likely that someone else has already worked out all the most annoying bugs for you.

Thanks to the ease with which users can view and modify source code, it’s also more likely that a program has been tinkered with, improved, and secured over time.

When many developers contribute, they bring their own unique expertise and experiences. This can result in a product far more robust and capable than one a single developer can produce.

Of course, being as varied as the people who build them, not all open source projects are created equal, nor maintained to be equally secure.

There are many factors that affect a project’s suitability for your use case. Here are a few general considerations that make a good starting point when choosing an open source project.

How to choose an open source project

As its most basic requirements, a good software project is reliable, easy to understand, and has up-to-date components and security. There are several indicators that can help you make an educated guess about whether an open source project satisfies these criteria.

Who’s using it

Taken in context, the number of people already using an open source project may be indicative of how good it is.

If a project has a hundred users, for instance, it stands to reason that someone has tried to use it at least a hundred times before you found it. Thus by the ancient customs of “I don’t know what’s in that cave, you go first,” it’s more likely to be fine.

You can draw conclusions about a project’s user base by looking at available statistics. Depending on your platform, these may include the number of downloads, reviews, issues or tickets, comments, contributions, forks, or “stars,” whatever those are.

Evaluate social statistics on platforms like GitHub with a grain of salt. They can help you determine how popular a project may be, but only in the same way that restaurant review apps can help you figure out if you should eat at Foo’s Grill & Bar.

Depending on where Foo’s Grill & Bar is, when it opened, and how likely people are to be near it when the invariable steak craving should call, having twenty-six reviews may be a good sign or a terrible one.

While you would not expect a project that addresses a very obscure use case or technology to have hundreds of users, having a few active users is, in such a case, just as confidence-inspiring.

External validation can also be useful. For example, packages that are included in a Linux operating system distribution (distro) must conform to stringent standards and undergo vetting. Choosing software that is included in a distro’s default repositories can mean it’s more likely to be secure.

Perhaps one of the best indications to look for is whether a project’s development team is using their own project. Look for issues, discussions, or blog posts that show that the project’s creators and maintainers are using what they’ve built themselves. Commonly referred to as “eating your own dog food," or “dogfooding,” it’s an indicator that the project is most likely to be well-maintained by its developers.

Who’s building it

The main enemy of good open source software is usually a lack of interest. The parties involved in an open source project can make the difference between a flash-in-the-pan library and a respected long-term utility. Multiple committed maintainers, even making contributions in their spare time, have a much higher success rate of sustaining a project and generating interest.

Projects with healthy interest are usually supported by, and in turn cultivate, a community of contributors and users.

New contributors may be actively welcomed, clear guides are available explaining how to help, and project maintainers are available and approachable when people have inevitable questions.

Some communities even have chat rooms or forums where people can interact outside of contributions. Active communities help sustain project interest, relevance, and its ensuing quality.

In a less organic fashion, a project can also be sustained through organizations that sponsor it. Governments and companies with financial interest are open source patrons too, and a project that enjoys public sector use or financial backing has added incentive to remain relevant and useful.

How alive is it

The recency and frequency of an open source project’s activity is perhaps the best indicator of how much attention is likely paid to its security. Look at releases, commit history, changelogs, or documentation revisions to determine if a project is active. As projects vary in size and scope, here are some general things to look for.

Maintaining security is an ongoing endeavor that requires regular monitoring and updates, especially for projects with third-party components. These may be libraries or any part of the project that relies on something outside itself, such as a payment gateway integration.

An inactive project is more likely to have outdated code or use outdated versions of components. For a more concrete determination, you can research a project’s third-party components and compare their most recent patches or updates with the project’s last updates.

Projects without third-party components may have no outside updates to apply. In these cases, you can use recent activity and release notes to determine how committed a project’s maintainers may be.

Generally, active projects should show updates within the last months, with a notable release within the last year. This can be a good indication of whether the project is using an up-to-date version of its language or framework.

You can also judge how active a project may be by looking at the project maintainers themselves. Active maintainers quickly respond to feedback or new issues, even if it’s just to say, “We’re on it.”

If the project has a community, its maintainers are a part of it. They may have a dedicated website or write regular blogs. They may offer ways to contact them directly and privately, especially to raise security concerns.

Can you understand it

Having documentation is a baseline requirement for a project that’s intended for anyone but its creator to use. Good open source projects have documentation that is easy to follow, honest, and thorough.

Having well-written documentation is one way a project can stand out and demonstrate the thoughtfulness and dedication of its maintainers.

A “Getting Started” section may detail all the requirements and initial set up for running the project. An accurate list of topics in the documentation enables users to quickly find the information they need. A clear license statement leaves no doubt as to how the project can be used, and for what purposes.

These are characteristic aspects of documentation that serves its users.

A project that is following sound coding practices likely has code that is as readable as its documentation. Code that is easy to read lends itself to being understood. Generally, it has clearly defined and appropriately-named functions and variables, a logical flow, and apparent purpose. Readable code is easier to fix, secure, and build upon.

How compatible is it

A few factors will determine how compatible a project is with your goals. These are objective qualities, and can be determined by looking at a project’s repository files. They include:

• Code language
• Specific technologies or frameworks
• License compatibility

Compatibility doesn’t necessarily mean a direct match. Different code languages can interact with each other, as can various technologies and frameworks. You should carefully read a project’s license to understand if it permits usage for your goal, or if it is compatible with a license you would like to use.

Ultimately, a project that satisfies all these criteria may still not quite suit your use case. Part of the beauty of open source software, however, is that you may still benefit from it by making alterations that better suit your usage. If those alterations make the project better for everyone, you can pay it back and pay it forward by contributing your work to the project.

Proper care and feeding of an open source project

Once you adopt an open source project, a little attention is required to make sure it continues to be a boon to your goals.

While its maintainers will look after the upstream project files, you alone are responsible for your own copy. Like all software, your open source project must be well-maintained in order to remain as secure and useful as possible.

Have a system that provides you with notifications when updates for your software are made available. Update software promptly, treating each patch as if it were vital to security – it may well be.

Keep in mind that open source project creators and maintainers are, in most cases, acting only out of the goodness of their own hearts. If you’ve got a particularly awesome one, its developers may make updates and security patches available on a regular basis. It’s up to you to keep tabs on updates and promptly apply them.

As with most things in software, keeping your open source additions modular can come in handy. You might use git submodules, branches, or environments to isolate your additions. This can make it easier to apply updates or pinpoint the source of any bugs that arise.

So although an open source project may cost no money, caveat emptor, which means, “Jimmy, if we get you a puppy, it’s your responsibility to take care of it.”

Adding dependencies to a project often helps you not reinvent the wheel. But at the same time it can cause issues in many different aspects of the project:

• Versioning: sometimes dependencies can require specific versions of other dependencies and this can cause hiccups in your app
• Bundling: you need to be careful not to end up with too much extra code that will bloat your bundles
• Updating: JavaScript moves fast, and if you don't update packages regularly you'll be playing Jenga in the future.

There are different tools to cover the task of updating dependencies, like Dependencies.io, Snyk, and Dependabot. Since I have been using Dependabot for a while, I decided to write about my experience.

Dependabot is a tool acquired by GitHub a year ago that checks dependency files from different languages (Ruby, JavaScript, Python, PHP, Elixir, to name a few) and finds new versions of libraries you are using in your project. Here is the setup:

Daily updates can be overwhelming, and I think that weekly updates have a better cost/benefit. Also, I assign myself the Pull Requests so I can get notifications as soon they are opened.

How to use Dependabot effectively

Dependabot includes, in each PR, release notes, changelogs, commit links and vulnerability details whenever available. This is useful because you can take a look at the information and decide to proceed or not.

However, as pragmatic programmers, we want to ensure things won't break. The PR details are important but more than that, we want a simulation of all (or almost all) deliverables that the project has.

This screenshot shows what happens every time a PR is opened in the components library codebase of my work.

• Tests (Jest / Bundle): the Jest task will test the React components while the Bundle task will simulate the bundling commands we run when we want to update the package in the NPM registry
• Linters (Stylesheets / JavaScript): the stylesheet files follow a custom sass-lint setup and the JS code follows a series of ESLint rules. If a PR introduces a new version of a linter with new rules, we will be able to capture that.
• Cypress (Screenshot Testing / Accessibility Testing): if a new package introduces changes that may be reflected in the look and feel of components, Cypress will capture the difference, screenshot it, and store in S3. Since Cypress needs a live version of the documentation website, we also get the Gatsby build process covered.

With all these steps, it is very unlikely an external package will break our master branch. Kudos to my co-worker Grant Lee that also works on this project.

_Also posted on my blog. If you like this content, follow me on Twitter and GitHub. Cover photo by Zhang Kenny on Unsplash_

Webpack is a powerful bundler and dependency manager used by many enterprise-level companies as tooling for their front-end code.

Typically, webpack is configured when a project is first set up, and small tweaks are then made to the config files as needed from time to time. Because of this, many developers don’t have a lot of experience working with webpack.

In this hands-on tutorial, we’ll go through the basics of setting up your very own production-ready webpack config using webpack 4. We’ll discuss output management, asset management, dev and prod configs, Babel, minification, cache busting, and more.

Webpack bundles your code

Let's get started!

Demo App

For the purposes of this demo, we'll be setting up a webpack config from scratch using webpack 4. Our app will just use vanilla JavaScript so that we don't get bogged down with any framework-specific details. The actual app code will be pretty small so that we can focus more on webpack.

If you'd like to follow along, all of the code in this article can be found in GitHub. The starting point is found here, and the finished result is found here.

Starting Point

To begin, we'll start out with just a few files in our project directory. The directory structure looks like this:

webpack-demo
 |_ src
    |_ index.js
 |_ .gitignore
 |_ index.html
 |_ package.json
 |_ README.md
 |_ yarn.lock

The index.html file is nice and simple, just a page header and a script tag:

<!doctype html>
<html>
  <head>
    <title>Webpack Training 1</title>
  </head>
  <body>
    <h1>Webpack Training 1</h1>
    <script src="./src/index.js"></script>
  </body>
</html>

The script tag references our ./src/index.js file, which has just a few lines of JavaScript in it that outputs the text, "Hello from webpack!":

const p = document.createElement('p')
p.textContent = 'Hello from webpack!'
document.body.append(p)

If you drag the index.html file into your browser, you should be able to view our simple web page:

Demo app output 1 - hello from webpack

Install Dependencies

I've included webpack and webpack-cli as devDependencies in the package.json file.

To install those, run:

yarn install

Webpack Test Run

Webpack 4 is set up as a "zero config" tool, meaning that you can run it out of the box without doing any initial configuration. Now, for any real project you will need to do some configuration, but it's nice that you can at least do a quick sanity check to ensure that webpack is able to run without having to go through a bunch of initial configuration steps.

So, let's check it out. Run:

yarn webpack

You should now see a dist directory created in your project directory. And inside it you should see a main.js file, which is our minified code.

Great! Webpack appears to be working.

Reference the Output Code

OK, now that we have JavaScript code in our dist directory, let's have our index.html file reference that. Instead of the script tag looking like this:

<script src="./src/index.js"></script>

Let's change it to this:

<script src="./dist/main.js"></script>

Now, refresh the page in your browser, and you should still see the exact same output, only this time the "Hello from webpack!" text is being generated by the ./dist/main.js file now.

Demo app output 2 - no changes

Create a Webpack Config File

Now that we have webpack installed and have gone through a quick sanity check exercise, let's create an actual webpack config file. Create a file called webpack.config.js and place the following code inside it:

const path = require('path')

module.exports = {
  entry: './src/index.js',
  output: {
    filename: 'main.js',
    path: path.resolve(__dirname, 'dist')
  }
}

The entry property tells webpack where our source code is located. It is the "entry point" for our app.

The output property tells webpack what to call the output file and which directory to place it in.

Simple enough, right?

Now let's create an npm script in our package.json file:

"scripts": {
  "build": "webpack --config=webpack.config.js"
}

Now we can run our build process with the command yarn build. Go ahead and run that command to verify you have things set up properly. You could even delete your dist directory prior to running the yarn build command to verify that the directory is being generated.

Change the Output File Name

Now, just for fun, let's change the output file name. To do this, we'll open up our webpack.config.js file and change the output property from this:

output: {
  filename: 'main.js',
  path: path.resolve(__dirname, 'dist')
}

To this:

output: {
  filename: 'tacos.js',
  path: path.resolve(__dirname, 'dist')
}

Now run yarn build again to generate the output. You should see a tacos.js file in your dist directory now.

But wait! We also see the old main.js file in our dist directory too! Wouldn't it be nice if webpack could delete the old unneeded output each time we do a new build?

There's got to be a plugin for that.

Webpack Plugins

_Photo by [Unsplash](https://unsplash.com/@feelfarbig?utm_source=ghost&utm_medium=referral&utm_campaign=api-credit">Feelfarbig Magazine / <a href="https://unsplash.com/?utm_source=ghost&utm_medium=referral&utmcampaign=api-credit)

Webpack has a rich ecosystem of modules called "plugins", which are libraries that can modify and enhance the webpack build process. We'll explore a handful of helpful plugins as we continue to improve our webpack config throughout the rest of this article.

CleanWebpackPlugin

_Photo by [Unsplash](https://unsplash.com/@honest?utm_source=ghost&utm_medium=referral&utm_campaign=api-credit">The Honest Company / <a href="https://unsplash.com/?utm_source=ghost&utm_medium=referral&utmcampaign=api-credit)

OK, back to our problem. It'd be nice if we could clean up the dist directory before each new build. There's a plugin for that!

We can use the CleanWebpackPlugin to help us here. First, we need to install it in our project:

yarn add --dev clean-webpack-plugin

To use it, we'll simply require the plugin in our webpack.config.js file and then include it in the plugins array in our config setup:

const path = require('path')
const { CleanWebpackPlugin } = require('clean-webpack-plugin')

module.exports = {
  entry: './src/index.js',
  output: {
    filename: 'main.js',
    path: path.resolve(__dirname, 'dist')
  },
  plugins: [
    new CleanWebpackPlugin()
  ]
}

Now run yarn build again, and you should see only a single output file in your dist directory. Problem solved!

HTMLWebpackPlugin

_Photo by [Unsplash](https://unsplash.com/@rxspawn?utm_source=ghost&utm_medium=referral&utm_campaign=api-credit">Florian Olivo / <a href="https://unsplash.com/?utm_source=ghost&utm_medium=referral&utmcampaign=api-credit)

One other thing that's a little annoying with our setup is that any time we change the output file name in our webpack.config.js file, we also have to change that file name we reference in our script tag in our index.html file. Wouldn't it be nice if webpack could manage that for us?

There's a plugin for that! We can use the HTMLWebpackPlugin to help us manage our HTML file. Let's install it in our project now:

yarn add --dev html-webpack-plugin

Now let's move our index.html file inside our src directory so that it's a sibling to the index.js file.

webpack-demo
 |_ src
    |_ index.html
    |_ index.js
 |_ .gitignore
 |_ package.json
 |_ README.md
 |_ yarn.lock

We can also delete the script tag in our index.html file since we'll have webpack handle inserting the appropriate script tag for us. Delete that line so that your index.html file looks like this:

<!doctype html>
<html>
  <head>
    <title>Webpack Training 1</title>
  </head>
  <body>
    <h1>Webpack Training 1</h1>
  </body>
</html>

Now let's require this plugin in our webpack.config.js file and then include it in the plugins array in our config setup, just like we did for the first plugin:

const path = require('path')
const { CleanWebpackPlugin } = require('clean-webpack-plugin')
const HtmlWebpackPlugin = require('html-webpack-plugin')

module.exports = {
  entry: './src/index.js',
  output: {
    filename: 'main.js',
    path: path.resolve(__dirname, 'dist')
  },
  plugins: [
    new CleanWebpackPlugin(),
    new HtmlWebpackPlugin({
      filename: 'index.html',
      inject: true,
      template: path.resolve(__dirname, 'src', 'index.html'),
    }),
  ]
}

In those options for the HtmlWebpackPlugin, we specify the filename for what we'd like the output file to be called.

We specify for inject that we would like our JavaScript file to be injected into the body tag by setting the value to true.

And finally, for the template we supply the location of our index.html file in the src directory.

Sanity Check

_Photo by [Unsplash](https://unsplash.com/@glenncarstenspeters?utm_source=ghost&utm_medium=referral&utm_campaign=api-credit">Glenn Carstens-Peters / <a href="https://unsplash.com/?utm_source=ghost&utm_medium=referral&utmcampaign=api-credit)

OK, let's make sure everything is still working properly. Run yarn build, and verify that you see two files in your dist directory: index.html and main.js.

If you look closely in your index.html file, you'll see the main.js file referenced.

Now, open the ./dist/index.html file in your browser to verify that your page loads correctly. If you followed these steps correctly, your page should still be working:

Demo app output 3 - no changes

Create a Development Server

_Photo by [Unsplash](https://unsplash.com/@tvick?utm_source=ghost&utm_medium=referral&utm_campaign=api-credit">Taylor Vick / <a href="https://unsplash.com/?utm_source=ghost&utm_medium=referral&utmcampaign=api-credit)

We've made some good improvements so far using the CleanWebpackPlugin and the HtmlWebpackPlugin. As we've made these changes, we've had to manually run the yarn build command each time to see new changes in our app. We've also just been viewing the file in our browser rather than viewing the content served from a server running locally. Let's improve our process by creating a development server.

To do this, we'll use webpack-dev-server. First, we'll need to install it:

yarn add --dev webpack-dev-server

Now, let's split up our single webpack.config.js file into two separate config files, one for production and one for development. We'll call the file for production webpack.config.prod.js and the file for development webpack.config.dev.js.

Development Webpack Config

Here's our development config file:

const path = require('path')
const { CleanWebpackPlugin } = require('clean-webpack-plugin')
const HtmlWebpackPlugin = require('html-webpack-plugin')

module.exports = {
  mode: 'development',
  devtool: 'inline-source-map',
  devServer: {
    contentBase: './dist',
  },
  entry: './src/index.js',
  output: {
    filename: 'main.js',
    path: path.resolve(__dirname, 'dist')
  },
  plugins: [
    new CleanWebpackPlugin(),
    new HtmlWebpackPlugin({
      filename: 'index.html',
      inject: true,
      template: path.resolve(__dirname, 'src', 'index.html'),
    }),
  ]
}

Note that we've specified the mode as development now, and we've specified that we would like an inline-source-map for our JavaScript files, meaning that a source map is included at the end of each JavaScript file. For our dev server, we've specified that our content will be found in the dist directory.

All the rest of the development config has stayed the same.

Production Webpack Config

Now, here's our production config file:

const path = require('path')
const { CleanWebpackPlugin } = require('clean-webpack-plugin')
const HtmlWebpackPlugin = require('html-webpack-plugin')

module.exports = {
  mode: 'production',
  devtool: 'source-map',
  entry: './src/index.js',
  output: {
    filename: 'main.js',
    path: path.resolve(__dirname, 'dist')
  },
  plugins: [
    new CleanWebpackPlugin(),
    new HtmlWebpackPlugin({
      filename: 'index.html',
      inject: true,
      template: path.resolve(__dirname, 'src', 'index.html'),
    }),
  ]
}

This file also looks very similar to our original config file. Here we've specified that the mode is production and that we would like the source-map option for source maps, which provides separate source map files for minified code.

Production and Development NPM Scripts

Finally, let's add a few more npm scripts in our package.json file so that we can work with our development and production webpack configs:

"scripts": {
  "build": "webpack --config=webpack.config.prod.js",
  "build-dev": "webpack --config=webpack.config.dev.js",
  "start": "webpack-dev-server --config=webpack.config.dev.js --open"
}

Now, let's try out each of these scripts.

Run yarn build to see the production build output. You should see that the main.js file in your dist directory is minified and that it has an accompanying main.js.map source map file.

Now run yarn build-dev to see the development build output. You should see the main.js file in your dist directory, but now note that it is not minified.

Lastly, run yarn start to start up the development server. This will open up the app on http://localhost:8080/. No more having to view the files directly by just pulling them into your browser! We now have a real live development server!

The output you see should still look the same as it always has:

Demo app output 4 - no changes

Making Changes During Development

Now that we have a working dev server, let's experiment with making some simple changes to our ./src/index.js file. Instead of outputting "Hello from webpack!", let's change it to say "Hello from dev server!".

Save the file, and then see the page on your dev server automatically reload and update for you! That'll be a nice boost to your developer productivity.

Demo app output 5 - hello from dev server

Don't Repeat Yourself (DRY)

_Photo by [Unsplash](https://unsplash.com/@tobey_j?utm_source=ghost&utm_medium=referral&utm_campaign=api-credit">Tobias Jelskov / <a href="https://unsplash.com/?utm_source=ghost&utm_medium=referral&utmcampaign=api-credit)

Now that we have two separate webpack config files, one for development and one for production, you may have noticed that we have a lot of duplicated code between the two files.

Every developer out there has had the DRY principle drilled into their heads since day one: Don't repeat yourself. If you find yourself writing the same code in multiple places, it may be a good idea to turn that into shared code that can be written in one place and then used in multiple places. That way when you need to make changes, you only need to implement those changes in one place.

So, how can we clean up the duplication in our webpack config files? There's a plugin for that!

WebpackMerge

Merge

We can use the webpack-merge plugin to manage shared code that multiple config files rely on. To do this, we'll first install the package:

yarn add --dev webpack-merge

Now we'll create a third webpack config file called webpack.config.common.js. This is where we'll keep our shared code. Right now, our development and production config files share the same entry point, output, and plugins. All that differs between the two files are the mode, source map, and dev server.

So, the contents of our webpack.config.common.js file will be:

const path = require('path')
const { CleanWebpackPlugin } = require('clean-webpack-plugin')
const HtmlWebpackPlugin = require('html-webpack-plugin')

module.exports = {
  entry: './src/index.js',
  output: {
    filename: 'main.js',
    path: path.resolve(__dirname, 'dist')
  },
  plugins: [
    new CleanWebpackPlugin(),
    new HtmlWebpackPlugin({
      filename: 'index.html',
      inject: true,
      template: path.resolve(__dirname, 'src', 'index.html'),
    }),
  ]
}

And now, we can merge this shared config object into our development config like this:

const merge = require('webpack-merge')
const commonConfig = require('./webpack.config.common')

module.exports = merge(commonConfig, {
  mode: 'development',
  devtool: 'inline-source-map',
  devServer: {
    contentBase: './dist',
  },
})

And we can merge the shared config object into our production config like this:

const merge = require('webpack-merge')
const commonConfig = require('./webpack.config.common')

module.exports = merge(commonConfig, {
  mode: 'production',
  devtool: 'source-map',
})

Look how much shorter and cleaner those two files look! Beautiful!

Styling Our App

_Photo by [Unsplash](https://unsplash.com/@madebyvadim?utm_source=ghost&utm_medium=referral&utm_campaign=api-credit">Vadim Sherbakov / <a href="https://unsplash.com/?utm_source=ghost&utm_medium=referral&utmcampaign=api-credit)

Things are looking pretty good with our webpack configs so far. We have a working dev server and we've split out our code into development, production, and shared configuration files.

Let's start working on our actual app code now. The plain black and white page is a little boring to look at. Let's style it up!

In our src directory, let's create an index.css file and place the following lines of CSS inside it:

body {
  background: deeppink;
  color: white;
}

Then, in our ./src/index.js file, let's import that CSS file:

import './index.css'

Now, run yarn start to get our development server running again.

Oh no! We get an error!

ERROR in ./src/index.css 1:5
Module parse failed: Unexpected token (1:5)
You may need an appropriate loader to handle this file type, currently no loaders are configured to process this file. See https://webpack.js.org/concepts#loaders
> body {
|   background: deeppink;
|   color: white;
 @ ./src/index.js 1:0-20

What are these "loaders" it speaks of?

Webpack Loaders

_Photo by [Unsplash](https://unsplash.com/@kevin_butz?utm_source=ghost&utm_medium=referral&utm_campaign=api-credit">Kevin Butz / <a href="https://unsplash.com/?utm_source=ghost&utm_medium=referral&utmcampaign=api-credit)

Earlier, we discussed webpack plugins, which let you extend the webpack build process. There is also an ecosystem of webpack "loaders", which help webpack know how to understand and load different file types. Out of the box, webpack understands how to handle our JavaScript files, but it doesn't know what to do with CSS files yet. Let's fix that.

StyleLoader and CSSLoader

There are two loaders in particular that will be helpful for us here: style-loader and css-loader. Let's get those included in our project and then discuss how they work.

To start, as always, we'll need to install those two dependencies:

yarn add --dev style-loader css-loader

Then we can add them to our webpack.config.common.js file in the module rules section down at the bottom:

const path = require('path')
const { CleanWebpackPlugin } = require('clean-webpack-plugin')
const HtmlWebpackPlugin = require('html-webpack-plugin')

module.exports = {
  entry: './src/index.js',
  output: {
    filename: 'main.js',
    path: path.resolve(__dirname, 'dist')
  },
  plugins: [
    new CleanWebpackPlugin(),
    new HtmlWebpackPlugin({
      filename: 'index.html',
      inject: true,
      template: path.resolve(__dirname, 'src', 'index.html'),
    }),
  ],
  module: {
    rules: [
      {
        test: /\.css$/,
        use: ['style-loader', 'css-loader']
      }
    ]
  }
}

This section sets up rules for webpack so it knows what to do with each file it encounters. The test property is a regular expression that webpack checks against the file name. In this case, we want to handle files with a .css extension.

Then, the use property tells webpack what loader or loaders to use to handle files matching the criteria. Note that the order here matters!

Webpack loaders are read from right to left. So first the css-loader will be applied, and then the style-loader will be applied.

Now, what do these loaders actually do for us?

css-loader interprets and resolves imported CSS files that you reference in your JavaScript. So in this case, css-loader helps make this line work:

import './index.css'

Next, style-loader injects the CSS into the DOM. By default, style-loader takes the CSS it encounters and adds it to the DOM inside a style tag.

Let's restart our dev server by killing the current process (if you still have it running) and then starting it again with yarn start. Now, in the web browser, you should see this on https://localhost:8080/:

Demo app output 6 - adds pink and white colors

Oooh, so colorful!

A Note on Other Webpack Loaders

We won't cover loaders for other file types in this article, but be aware that there's a loader for everything imaginable! You can use file-loader or url-loader for loading images and other assets. You can use sass-loader to handle converting Sass/SCSS files to CSS before piping that output to css-loader and style-loader. Webpack can handle Less files too with less-loader if that's your preference.

The moral of the story is: For any given file type, there's a loader that can handle it.

BabelLoader

Ok, back to our demo app. We've written just a few lines of JavaScript so far. It'd be nice if we could write our JavaScript using new features that aren't well-supported in every browser yet. Babel is a JavaScript compiler that can turn ES6+ code into ES5 code.

And (you guessed it), there's a loader for that: babel-loader.

To set up babel-loader, we'll follow the instructions on their installation guide linked above.

First, we'll install our dependencies:

yarn add --dev babel-loader @babel/core

Next, we'll add a new rule to our module rules array in our webpack.config.common.js file:

const path = require('path')
const { CleanWebpackPlugin } = require('clean-webpack-plugin')
const HtmlWebpackPlugin = require('html-webpack-plugin')

module.exports = {
  entry: './src/index.js',
  output: {
    filename: 'main.js',
    path: path.resolve(__dirname, 'dist')
  },
  plugins: [
    new CleanWebpackPlugin(),
    new HtmlWebpackPlugin({
      filename: 'index.html',
      inject: true,
      template: path.resolve(__dirname, 'src', 'index.html'),
    }),
  ],
  module: {
    rules: [
      {
        test: /\.css$/,
        use: ['style-loader', 'css-loader']
      },
      {
        test: /\.(js|jsx)$/,
        exclude: /[\\/]node_modules[\\/]/,
        use: {
          loader: 'babel-loader',
        },
      },
    ]
  }
}

This will tell webpack that when it encounters .js or .jsx files to use Babel to transform the code. We use the exclude property to make sure Babel doesn't try to transform JavaScript files in our node_modules directory. Those are third-party dependencies that should already have been taken care of by their creators.

Next, we'll add one more dependency for a Babel preset:

yarn add --dev @babel/preset-env

And then we'll create a .babelrc file where we can do other Babel configuration as needed. We'll keep our file pretty simple and just specify the Babel preset that we want to use:

{
  "presets": ["@babel/preset-env"]
}

And finally, let's write some ES6 code in our ./src/index.js file:

import './index.css'

const p = document.createElement('p')
p.textContent = 'Hello from webpack!'
document.body.appendChild(p)

const p2 = document.createElement('p')
const numbers1 = [1, 2, 3, 4, 5, 6]
const numbers2 = [7, 8, 9, 10]
const numbers3 = [...numbers1, ...numbers2]
p2.textContent = numbers3.join(' ')
document.body.appendChild(p2)

This is a really trivial example, but we're using the spread operator here to concatenate two arrays.

Now, if we kill our running process and run yarn start again, we should see this in the browser:

Demo app output 7 - adds numbers

Great! Everything is working nicely.

Temporarily Missing Styles

If you disable the cache in your browser and reload the page for our demo app, you may notice a slight blip in which the page appears with just the un-styled HTML, and then the page background turns pink and the text turns white as the styles are applied.

This behavior results from how style-loader works. As mentioned above, style-loader takes CSS and places it in a style tag in your HTML. Because of that, there's a brief period of time in which the style tag hasn't been appended yet!

Now, this is OK for a development environment, but we definitely wouldn't want this kind of behavior occurring in production. Let's fix that.

MiniCssExtractPlugin

Rather than injecting CSS into our HTML as style tags, we can use the MiniCssExtractPlugin to generate separate CSS files for us. We'll use this in our production config while still just using style-loader in our development config.

First, let's install the dependency in our project:

yarn add --dev mini-css-extract-plugin

Now in our webpack.config.common.js file let's remove the CSS rule since we'll be handling this differently in development and production. We're left with this in our shared config:

const path = require('path')
const { CleanWebpackPlugin } = require('clean-webpack-plugin')
const HtmlWebpackPlugin = require('html-webpack-plugin')

module.exports = {
  entry: './src/index.js',
  output: {
    filename: 'main.js',
    path: path.resolve(__dirname, 'dist')
  },
  plugins: [
    new CleanWebpackPlugin(),
    new HtmlWebpackPlugin({
      filename: 'index.html',
      inject: true,
      template: path.resolve(__dirname, 'src', 'index.html'),
    }),
  ],
  module: {
    rules: [
      {
        test: /\.(js|jsx)$/,
        exclude: /[\\/]node_modules[\\/]/,
        use: {
          loader: 'babel-loader',
        },
      },
    ]
  }
}

Now, in our webpack.config.dev.js file, let's add back in style-loader and css-loader that we just removed from our shared config:

const merge = require('webpack-merge')
const commonConfig = require('./webpack.config.common')

module.exports = merge(commonConfig, {
  mode: 'development',
  devtool: 'inline-source-map',
  devServer: {
    contentBase: './dist',
  },
  module: {
    rules: [
      {
        test: /\.css$/,
        use: ['style-loader', 'css-loader']
      },
    ]
  }
})

And finally, in our webpack.config.prod.js file, let's add in our new mini-css-extract-plugin:

const merge = require('webpack-merge')
const MiniCssExtractPlugin = require('mini-css-extract-plugin');
const commonConfig = require('./webpack.config.common')

module.exports = merge(commonConfig, {
  mode: 'production',
  devtool: 'source-map',
  module: {
    rules: [
      {
        test: /\.css$/,
        use: [
          MiniCssExtractPlugin.loader,
          'css-loader',
        ],
      },
    ],
  },
  plugins: [
    new MiniCssExtractPlugin({
      filename: '[name].[contenthash].css',
    }),
  ]
})

This one is a little different because it actually is both a plugin and a loader, so it goes in the module rules and in the plugins sections.

Also note that we use the square brackets in our file name to dynamically set the name to the original source file's name and also include the contenthash, which is a hash (an alphanumeric string) that represents the file's contents.

Now if you run yarn build this time to generate the production build, you should get some output in your terminal that looks like this:

Webpack production build output

Note that it actually generates a CSS file now, and the content hash is included in the file name.

Alright, problem solved! No more blip when the page loads in production since we have the styles included as a link tag to an actual CSS file.

Cache Busting

Since we've included the content hash in the generated CSS file, now is a good time to talk about cache busting. Why, you ask, would we want the content hash included in our file names? To help the browser understand when a file has changed!

Your browser tries to be helpful by caching files it has seen before. For example, if you've visited a website, and your browser had to download assets like JavaScript, CSS, or image files, your browser may cache those files so that it doesn't have to request them from the server again.

This means that if you visit the site again, your browser can use the cached files instead of requesting them again, so you get a faster page load time and a better experience.

So, what's the problem here? Imagine if we had a file called main.js used in our app. Then, a user visits your app and their browser caches the main.js file.

Now, at some later point in time, you've released new code for your app. The contents of the main.js file have changed. But, when this same user visits your app again, the browser sees that it needs a main.js file, notes that it has a cached main.js file, and just uses the cached version. The user doesn't get your new code!

To solve this problem, a common practice is to include the content hash in each file's name. As discussed earlier, the content hash is a string representation of the file's contents. If the file's contents don't change, the content hash doesn't change. But, if the file's contents do change, then the content hash also changes.

Because the file name will now change when the code changes, the browser will download the new file since it won't have that specific file name in its cache.

Including the Content Hash

To include the content hash in our JavaScript file names, we'll modify just one line of code in our webpack.config.common.js file. This line:

filename: 'main.js'

Will change to this line:

filename: '[name].[contenthash].js'

So that the entire file looks like this:

const path = require('path')
const { CleanWebpackPlugin } = require('clean-webpack-plugin')
const HtmlWebpackPlugin = require('html-webpack-plugin')

module.exports = {
  entry: './src/index.js',
  output: {
    filename: '[name].[contenthash].js', // this line is the only difference
    path: path.resolve(__dirname, 'dist')
  },
  plugins: [
    new CleanWebpackPlugin(),
    new HtmlWebpackPlugin({
      filename: 'index.html',
      inject: true,
      template: path.resolve(__dirname, 'src', 'index.html'),
    }),
  ],
  module: {
    rules: [
      {
        test: /\.(js|jsx)$/,
        exclude: /[\\/]node_modules[\\/]/,
        use: {
          loader: 'babel-loader',
        },
      },
    ]
  }
}

Now if you run yarn build, you'll see that both your JavaScript and your CSS have content hashes included:

Webpack production build output with content hashes included

If you run yarn build again and compare your new output to your old output, you'll notice that the content hashes are exactly the same both times.

But, if you edit your ./src/index.js file in any way and then run yarn build again, you'll get a new content hash because the content has changed! Try it!

Minifying CSS

Last but not least, we may want to minify our CSS. We're already minifying our JavaScript for the production build, but we're not minifying our CSS yet. Let's do that.

We can minimize our CSS by using the optimize-css-assets-webpack-plugin. Let's install that dependency now:

yarn add --dev optimize-css-assets-webpack-plugin

Now we can add that to an optimization section of our webpack.config.prod.js file:

const merge = require('webpack-merge')
const MiniCssExtractPlugin = require('mini-css-extract-plugin')
const OptimizeCssAssetsPlugin = require('optimize-css-assets-webpack-plugin')
const commonConfig = require('./webpack.config.common')

module.exports = merge(commonConfig, {
  mode: 'production',
  devtool: 'source-map',
  module: {
    rules: [
      {
        test: /\.css$/,
        use: [
          MiniCssExtractPlugin.loader,
          'css-loader',
        ],
      },
    ],
  },
  plugins: [
    new MiniCssExtractPlugin({
      filename: '[name].[contenthash].css',
    }),
  ],
  optimization: {
    minimizer: [
      new OptimizeCssAssetsPlugin({
        cssProcessorOptions: {
          map: {
            inline: false,
            annotation: true,
          },
        },
      }),
    ],
  },
})

Now if we run yarn build and then check out the contents of our dist directory, we can see that the resulting CSS is minified. Nice!

body{background:#ff1493;color:#fff}
/*# sourceMappingURL=main.66e0d6aeae6f3c6fb895.css.map */

But wait! If we look at our resulting JavaScript file, it's not minified! Hmmm. It was minified before, so what happened here?

The issue is that we're now manually configuring the optimization minimizer section of our webpack config. When that section isn't in the webpack config file, webpack defaults to using its own minimizer preferences, which includes minifying JavaScript when the mode is set to production.

Since we're now overriding those defaults by adding in our preferences for minifying CSS assets, we'll need to also explicitly include instructions for how we want webpack to minify JavaScript assets.

TerserWebpackPlugin

We can minify our JavaScript files using the TerserWebpackPlugin. Let's start by installing that dependency:

yarn add --dev terser-webpack-plugin

Then, in our webpack.config.prod.js file, let's add the terser-webpack-plugin to our optimization minimizer settings at the bottom of the file:

const merge = require('webpack-merge')
const MiniCssExtractPlugin = require('mini-css-extract-plugin')
const OptimizeCssAssetsPlugin = require('optimize-css-assets-webpack-plugin')
const TerserPlugin = require('terser-webpack-plugin')
const commonConfig = require('./webpack.config.common')

module.exports = merge(commonConfig, {
  mode: 'production',
  devtool: 'source-map',
  module: {
    rules: [
      {
        test: /\.css$/,
        use: [
          MiniCssExtractPlugin.loader,
          'css-loader',
        ],
      },
    ],
  },
  plugins: [
    new MiniCssExtractPlugin({
      filename: '[name].[contenthash].css',
    }),
  ],
  optimization: {
    minimizer: [
      new OptimizeCssAssetsPlugin({
        cssProcessorOptions: {
          map: {
            inline: false,
            annotation: true,
          },
        },
      }),
      new TerserPlugin({
        // Use multi-process parallel running to improve the build speed
        // Default number of concurrent runs: os.cpus().length - 1
        parallel: true,
        // Enable file caching
        cache: true,
        sourceMap: true,
      }),
    ],
  },
})

Now if we run yarn build and look at the output in the dist directory, we should see that both our CSS files and our JavaScript files are minified. There we go!

Wrapping Up

If you've followed along this far, I commend you!

_Photo by [Unsplash](https://unsplash.com/@katya?utm_source=ghost&utm_medium=referral&utm_campaign=api-credit">Katya Austin / <a href="https://unsplash.com/?utm_source=ghost&utm_medium=referral&utmcampaign=api-credit)

Let's review what we've learned so far:

• Webpack is a build tool for asset bundling and dependency management.
• Webpack can be configured by a config file.
• Plugins modify and extend the webpack build process.
• Loaders instruct webpack how to handle different file types.
• The clean-webpack-plugin can be used to remove old build artifacts from the dist directory.
• The html-webpack-plugin helps manage the HTML file, including injecting JavaScript into the file via script tags.
• webpack-dev-server creates a dev server to make local development easier.
• It's helpful to have separate webpack configs for development and production. You can share and merge config files using the webpack-merge plugin.
• We can handle styling our app by including loaders like css-loader, style-loader, sass-loader, less-loader, and the mini-css-extract-plugin (which functions as both a plugin and a loader).
• We can include new JavaScript syntax and features by using Babel and babel-loader.
• We can include content hashes in our file names to help with cache busting and managing new versions of our released code.
• We can minify our CSS with the optimize-css-assets-webpack-plugin.
• We can minify our JavaScript with the terser-webpack-plugin.

What's Next?

_Photo by [Unsplash](https://unsplash.com/@tomparkes?utm_source=ghost&utm_medium=referral&utm_campaign=api-credit">Tom Parkes / <a href="https://unsplash.com/?utm_source=ghost&utm_medium=referral&utmcampaign=api-credit)

Throughout this article, we've created a pretty respectable webpack config. All of these techniques we've discussed are industry standards and are common to use in enterprise-level projects.

But there's still more! Other advanced webpack topics include code splitting, lazy loading, tree shaking, and more!

If you're interested in exploring webpack more on your own, I'd highly recommend reading through the official webpack guides.

Again, all of the code we've gone through in this tutorial can be found in GitHub. The starting point is found here, and the finished result is found here.

Thanks for reading, and happy coding!