Eleventy --incremental builds: global data changes not propagating to dependent templates

Short answer

Eleventy's --incremental mode (v2/v3 era) builds a dependency graph between templates and data files. A change to a file under _data normally marks every template that statically references it as dirty, so those pages regenerate without a full rebuild. But the guarantee only covers statically detectable usage. There is no configuration flag to force all templates dirty, and in CI a full build is the safer default unless you deliberately persist the cache.

1. What incremental mode actually guarantees

Confirmed behavior: Eleventy tracks which templates consume which data files and rebuilds the consuming templates when a data file changes. The data cascade (directory data files, front matter, layout chaining) is respected, but only where Eleventy can statically associate the data source with the template.

The likely explanation for missed rebuilds is one of these dependency shapes:

• Runtime-resolved data access. If a template gets data through a custom filter or shortcode that loads a file inside a function, Eleventy never sees the edge, so editing that file leaves the page stale.
• JavaScript data files with internal imports. Eleventy tracks the data file's own modification state, not the modules it imports. Editing a helper imported by _data/site.js may not dirty anything.
• Distorted timestamps. Networked or containerized filesystems can produce unreliable mtimes, which the cache depends on.

2. Forcing templates dirty

There is no documented option to declare "everything depends on this file." The practical patterns are:

1. Keep data access static: reference _data values directly in templates rather than loading files inside filters or shortcodes.
2. For JS data files, inline the changing logic or touch the data file itself when an imported helper changes.
3. When dependency coverage is uncertain, drop the flag and run a full build for that change.

3. CI: cache persistence vs full builds

Persisting the cache directory across CI runs is fragile. CI jobs typically start from a fresh clone, so all file timestamps change, which can make the incremental cache unreliable and produce stale or skipped output. A full build in CI is the recommended default. If you need incremental builds in CI, you must preserve the cache folder between runs and ensure the filesystem reports accurate modification times — otherwise don't trust it.

Verify before trusting it

Run a minimal reproduction against your installed version:

# add _data/meta.json, reference it in one page, then:
npx eleventy --incremental
# edit _data/meta.json
npx eleventy --incremental
# confirm the consuming page's output changed

Also test any dynamic pattern (a filter that reads a file) by editing the underlying file and checking whether the page regenerates. If it doesn't, require full builds for those edits. In CI, diff a full build against an incremental build on a fresh clone — matching page counts and content is the bar for trusting cache persistence.

Note: this reflects v2/v3-era behavior; dependency-tracking internals have evolved across releases, so confirm against the version pinned in your project.