Features: Incremental Build

"Simplicity -- the art of maximizing the amount of work not done -- is essential." - Agile Manifesto, 10th principle

Incremental build has been a core concept of build systems as far back as "make". An "incremental" build occurs after a "full" build, without a "clean" taking place between them. This means that incremental builds can take advantage of the output from the previous build, only executing the parts of the build that are necessary to account for any changes that have been made since the last build.

Incremental builds are a frequent occurrence in typical developer workflows; so keeping incremental builds as fast as possible makes a big difference in developer efficiency. That's why support for incremental builds is built into the core Casper framework. Every core Casper task supports incremental execution by default: if nothing that the task cares about has changed since the last time the task ran successfully, the task doesn't run again. Moreoever, custom tasks can easily support incremental execution simply by declaring their inputs and outputs. This allows Casper to track whether changes have occurred, and skip the task when appropriate.

Efficient incremental builds are so critical to the developer experience that Casper actually requires all tasks to be incremental. Tasks which cannot be incremental by design must declare themselves as non-incremental. Any other task which appears not to be incremental - either because it does not declare inputs and outputs, or because it is behaving in a non-incremental manner despire declaring its inputs and outputs - will produce a warning in the build output. A single non-incremental task can cause an entire build process to execute unnecessarily; requiring tasks to be incremental helps ensure that non-incremental tasks do not accidentally sneak in to the build.