This is our fork of parcel@1 with updated dependencies
We currently use it for our builds to avoid warnings about deprecated dependencies in the last parcel@1.12.4 release (2019)
Given the environment variable SNAPVIEW_ENV=dev, the elm debugger will be active for builds.
- 🚀 Blazing fast bundle times - multicore compilation, and a filesystem cache for fast rebuilds even after a restart.
- 📦 Out of the box support for JS, CSS, HTML, file assets, and more - no plugins to install.
- 🐠 Automatically transforms modules using Babel, PostCSS, and PostHTML when needed - even
node_modules. - ✂️ Zero configuration code splitting using dynamic
import()statements. - 🔥 Built in support for hot module replacement
- 🚨 Friendly error logging experience - syntax highlighted code frames help pinpoint the problem.
- Install with yarn:
yarn global add parcel-bundleror with npm:
npm install -g parcel-bundler- Parcel can take any type of file as an entry point, but a HTML or JavaScript file is a good place to start. If you link your main JavaScript file in the HTML using a relative path, Parcel will also process it for you, and replace the reference with a URL to the output file.
<html>
<body>
<script src="./index.js"></script>
</body>
</html>- Parcel has a development server built in which will automatically rebuild your app as you change files and supports hot module replacement for fast development. Just point it at your entry file:
parcel index.html- Now open http://localhost:1234/ in your browser. If needed, you can also override the default port with the
-poption. Add--opento automatically open a browser.
See parceljs.org for more documentation!
Based on a reasonably sized app, containing 1726 modules, 6.5M uncompressed. Built on a 2016 MacBook Pro with 4 physical CPUs.
| Bundler | Time |
|---|---|
| browserify | 22.98s |
| webpack | 20.71s |
| parcel | 9.98s |
| parcel - with cache | 2.64s |
There are many web application bundlers out there with huge adoption, including webpack and browserify. So, why do we need another one? The main reasons are around developer experience.
Many bundlers are built around configuration and plugins, and it is not uncommon to see applications with upwards of 500 lines of configuration just to get things working. This configuration is not just tedious and time consuming, but is also hard to get right and must be duplicated for each application. Oftentimes, this can lead to sub-optimized apps shipping to production. parcel is designed to need zero configuration: just point it at the entry point of your application, and it does the right thing.
Existing bundlers are also very slow. Large applications with lots of files and many dependencies can take minutes to build, which is especially painful during development, when things change all the time. File watchers can help with rebuilds, but the initial launch is often still very slow.
parcel utilizes worker processes to compile your code in parallel, utilizing modern multicore processors. This results in a huge boost in speed for initial builds. It also has a file system cache, which saves the compiled results per file, for even faster subsequent startups.
Finally, existing bundlers are built around string loaders/transforms, where the transform takes in a string, parses it, does some transformation, and generates code again. Oftentimes, this ends up causing many parses and code generation runs on a single file, which is inefficient. Instead, parcel's transforms work on ASTs, so that there is one parse, many transforms, and one code generation per file.
parcel transforms a tree of assets into a tree of bundles. Many other bundlers are fundamentally based around JavaScript assets, with other formats tacked on - for example, by default inlined as strings into JS files. parcel is file-type agnostic - it will work with any type of assets the way you'd expect, with no configuration.
parcel takes as input a single entry asset, which could be any file type: JS, HTML, CSS, image, etc. There are various asset types defined in parcel which know how to handle specific file types. The assets are parsed, their dependencies are extracted, and they are transformed to their final compiled form. This creates a tree of assets.
Once the asset tree has been constructed, the assets are placed into a bundle tree. A bundle is created for the entry asset, and child bundles are created for dynamic imports, which cause code splitting to occur. Child bundles are also created when assets of a different type are imported. For example, if you imported a CSS file from JavaScript, it would be placed into a sibling bundle in correlation to the associated JavaScript file. If an asset is required in more than one bundle, it is hoisted up to the nearest common ancestor in the bundle tree, so it is not included more than once.
After the bundle tree is constructed, each bundle is written to a file by a packager specific to the file type. The packagers know how to combine the code from each asset together into the final file that is loaded by a browser.
All feedback and suggestions are welcome!
This project exists thanks to all the people who contribute. [Contribute].
Thank you to all our backers! 🙏 [Become a backer]
Support this project by becoming a sponsor. Your logo will show up here with a link to your website. [Become a sponsor]
MIT