Introduction to the new packaging tool -Parcel

The characteristics of the Parcel

• Fast packaging – multi-core compilation, along with file system caching, allows for a quick rebuild even after a reboot.
• Supports JS, CSS, HTML, file resources, etc. – no need to install any plug-ins.
• Automatically use Babel, PostCSS, and PostHTML to automatically convert modules – even node_modules – when needed.
• Zero configuration code splitting, using dynamic import statements.
• Built-in support for module hot replacement
• Friendly error logging experience, syntax highlighted code frames help pinpoint problems.

To compare

Based on a reasonably sized application that contains 1726 modules and is 6.5M uncompressed. Built in 2016, the MAcBook Pro has a 4-core physical CPU.

Why do you need a Parcel?

There are plenty of packaging tools out there, including WebPack and Browserify. So why do we need another one? The main reason is the experience of the developers.

Many packaging tools are built around configuration and plug-ins, and it’s not uncommon to have more than 500 lines of configuration in order for an application to work properly. These configurations are cumbersome and time consuming. Often, this can result in sub-optimized applications being sent to production. A parcel is designed to be zero-configuration: all you need to do is point it to the entry point of your application and it will work.

Existing packaging tools are very slow. Large applications with lots of files and dependencies can take several minutes to build, which can become particularly painful over time during development. Listening for file changes can help rebuild, but the initial startup is still very slow. Parcel leverages worker threads to compile your code, taking advantage of modern multicore processor capabilities. This resulted in a significant increase in the speed of initial builds. It also has a file system cache that stores the compilation results of each file for faster subsequent startup.

Finally, existing packaging tools are built around string loading/transformation, where a transformation takes a string, parses it, does some transformation, and then generates the code again. Often this results in a lot of parsing and code generation running in a single file, which is very inefficient. Instead, the transformation of a parcel works on the AST, so there is only one parsing, multiple transformations, and one code generation per file.

How does a Parcel work?

Parcel transforms the resource tree into a bundle tree. Many other packaging tools are basically based on JS resources, and other formats are pasted – for example, embedded in JS as strings by default. A parcel is file type neutral – it works with any type of resource the way you expect it to, no configuration required.

Parcel takes an entry point as input and can be any type: JS files, HTML, CSS, images, etc. There are various resource types defined in a Parcel that know how to handle specific resource types. The resource file is parsed, its dependencies extracted, and converted into its final compiled form. This creates a resource tree.

Once the resource tree is built, the resources are put into a bundle tree. Creating a bundle for the imported resource and creating sub-bundles for the dynamically imported resource causes code splitting to occur. Subbundles are created when importing different types of resources. For example, if you import a CSS file in a JS file, it will be packaged into its js sibling bundle. If a resource needs more than one bundle, it will be packaged to its nearest common ancestor, so it will not be included more than once.

After the bundle tree is built, each package is written to a file with a wrapper of a specific file type.

The original address: https://github.com/parcel-bundler/parcel