Cargo in fact, bundles up subsequent tasks in to an array, so any tasks that are not immediately run get bundled in to another run later. This helps when lots of changes have been made in a short period of time.
For file changes that do not require a webpack run, ie HTML, the assets will still be copied to the output directory, but webpack will not run (as it’s too slow).
to configure pipeline specific options like TypeScript support.
At the time this has been added, `core/config` didn't handle the loading
of configuration files for pipeline related tasks yet.
This commit ensures a dapp's `pipeline.json` will be loaded and used to
configure Embark's webpack process as part of Embark's `Config` initialization.
As part of a bigger refactoring to make Embark's build pipeline pluggable,
this commit moves the watcher into its own plugin module so it can be
consumed via Embark's event bus.
It also introduces new command handlers for all watcher related APIs respectively:
- watcher:start
- watcher:stop
- watcher:restart
This is the first step of refactoring Embark's pipeline abstraction into
dedicated plugin modules that take advantage of Embark's event system.
With this commit we're moving `Pipeline` into `lib/modules/pipeline` and
introduce a new command handler `pipeline:build`. Embark's engine now
requests builds via this command handler.
Notice that `Watch` still lives in `lib/pipeline` as this is a step-by-step
refactoring to reduce chances of introducing regressions.
emizzle
Jonathan Rainville
Michael Bradley, Jr
Pascal Precht