Parcel is designed to be very modular,
Here is an excerpt from the default config that the
parcel CLI uses. Generally, there are three categories of plugin types (with regards to the configuration):
- only one plugin for the whole build (bundler)
- a list of plugins that run sequentially (namers/resolvers/reporters)
- the plugin(s) are specified per asset/bundle type (transformers/packagers/optimizers)
- runtimes are the exception here, because they are specified per context.
A filetype is specified by a glob which is matched against the whole filepath (the pipelines are matched in order of declaration), so you could use different plugins depending on the input/output filepath:
- The globs for transformers are matched against the asset (input) path.
- The globs for packagers and optimizers are matched against the bundle (output) path.
¶ Extending configs
A common usecase is extending the default config, for this reason the
extends field can be a config package or an array of config packages to extend.
The observant reader might have noticed that the last config example didn't include
@parcel/transformer-js, which is required for
This is solved with pipelines. A Typescript asset is first processed by the
ts pipeline and once the
@parcel/transformer-typescript-ts plugin sets the asset type (which is essentially equivalent to the file extension) to
js, Parcel reevaluates how the asset should be further processed. In this case, it will be put into the
js pipeline specified in
@parcel/config-default. This way,
@parcel/transformer-js will still be executed.
If a transformer doesn't change the asset type and you still want to continue processing this asset, add
"..." to continue the transformation (in an extended config). This can be useful if you want to modify an asset without changing its type and let a already defined pipeline handle the translation/dependency registration.
¶ Named Pipelines
In addition to the asset type-based pipelines, there are named pipelines, which enable you to import a single asset type in different ways (e.g. formats).
Named pipelines are specified using a procotol-like syntax, e.g.
import myLogo from "url:./logo.png";
Here is an example on how you achieve a url dependency that doesn't create a new bundle but is rather inlined as a data url.
As you can see,
... is now used to make sure that
data-url:./worker.js will still be processed with the
js pipeline (the named pipeline specifier only applies for the first pipeline match).
Named pipelines are currently implemented for transformers and optimizers (the named pipeline is inheirited from the entry asset).
¶ Predefined (offical) named pipelines
data-url:See above for an example. It isn't replaced by an URL to a new bundle but instead an isolated data url.
url:Needed when e.g. importing "normal" assets such as media files as a URL