Parcel bundler: Production builds and best practices

You’ll need to add a little configuration, but it’s a small price to pay for super-smooth app bundling

Parcel bundler: Production builds and best practices
Thinkstock

Over the past couple of weeks I’ve been playing around with Parcel, the zero-configuration web application bundler. I had a few issues with automagical dependency management, but for the most part Parcel has been a delight. This week we’ll look at building Parcel projects for production. I’ll cover some patterns and best practices for using Parcel in serious projects and outline some gotchas and issues to watch.

Building for production with Parcel

The process for building assets for production is as straightforward as running parcel build index.html. Parcel essentially runs the same logic we’ve already seen but only runs once instead of running continuously in a watch mode. The dist directory is where your built assets go by default, which is the same directory that parcel index.html outputs to while you’re developing. If you have opinions or preferences about this naming structure, simply pass in a parameter to parcel build that specifies the desired location of the output directory: --out-dir or -d for shorthand.

Always use a local Parcel install

If you’re doing a little toy project prototype that you don’t expect to survive past the day, using the global Parcel installation is fine. If you’re serious about the project however, you’ll set up a minimal amount of configuration in order to manage the Parcel binary. This ensures that multiple projects using Parcel will not share a common dependency that creates headaches when you need to upgrade that dependency. Here is a minimal package.json you can use to handle this:

{
  "scripts": {
    "start": "parcel index.html"
  },
  "dependencies": {
    "parcel-bundler": "^1.11.0"
  }
}

Now all you have to do is run npm run start or yarn start in order to run Parcel in development mode. One additional benefit of adding a package.json file is that Parcel will update it to reflect the dependencies it automagically installs.

Avoid automagical dependency installation

It’s really nice to just add an import statement and continue coding without having to mess with npm install … up until the point that you need to maintain software and have it run reliably in different environments over time. Automagical dependency resolution is pretty awesome, but you’re asking for a world of hurt if you don’t explicitly document and pin your dependencies. As mentioned in the last section, adding a package.json file will give Parcel a place to record the dependencies it’s installing, but it doesn’t play well with others. If you install some dependencies manually at a specific version, Parcel may overwrite those versions with its own resolved versions. Add the --no-autoinstall flag to your start script to disable this feature completely.

Make sure Parcel works for you

This seems obvious, but because Parcel aims to accomplish so many different things, it’s hard to provide a general recommendation across whatever you might want. For the JavaScript projects I tend to work on, Parcel worked well, but I ran into some strange compatibility and sequencing issues once I started adding and intertwining asset types. It is highly unlikely that you’ll be mounting a React app within an Elm app, which breaks hot-reloading, but the fact that the combination produces unexpected behavior shows that Parcel is not bullet-proof: Other combinations could also produce unexpected behavior. Make sure your combination of assets works well.

Don’t forget to contribute

Parcel is an open source project, which could always use some help from the community. If you like using it, don’t forget that you can give back to the project and make the experience better for everyone. This could include feature work or bug fixes, but documentation is a highly valuable contribution as well. The documentation for certain asset pages could use some love and maintainers are always looking for documentation contributors. If you’re interested, check out their contribution guidelines to understand how to seamlessly integrate into the project.

Despite the minor hiccups, Parcel is a project I will continue to use. I’ll be following the Parcel 2 development board to see how the future of Parcel is shaping up. Have your own impressions? Continue the conversation on Twitter: @freethejazz.

Copyright © 2019 IDG Communications, Inc.