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:
