Order of Operations Jump to heading
From a very high level, Eleventy’s internal order of operations is such:
- Find any file matching a valid Eleventy file extension in the Input directory. (e.g.
./src/**.njk
or./docs/**.md
) - Iterate over the files.
- If it doesn’t match a template file extension, treat it as a passthrough copy.
- If it does match a template file extension, continue processing as an Eleventy template.
- Start the asynchronous copy of passthrough copy. Both configuration specified passthrough copy and non-template-matching file extension files. This will continue while templates are being processed.
- Initial Data Cascade is generated for each template file. This includes all values from front matter, layouts, directory and file data files, global data.
- The data cascade does not yet include populated
collections
,templateContent
, or computedpage
values likepage.url
andpage.outputPath
.
- The data cascade does not yet include populated
- Dependency graph is created of the templates to process them in the correct order.
- This is a bit oversimplified (and some may mix and match if they aren’t dependent on each other) but from a high level the templates are processed like this (listed here in reverse order—
1
is processed first):- Templates that use Pagination and target
collections.all
- Templates that use Pagination and target
collections
- Templates that use Pagination and target a Configuration API added collection
- Templates that use Pagination and target any other Collection (those supplied via
tags
) - Templates that have
tags
specified - Templates that have no dependencies or are
eleventyExcludeFromCollections
- Templates that use Pagination and target
- Note: Eleventy does not automatically know what data is used inside of the template content at this stage. We use the specified front matter to know which templates supply collections and which templates consume collections. For a safety net we may add a front matter option to declare dependencies manually.
- This is a bit oversimplified (and some may mix and match if they aren’t dependent on each other) but from a high level the templates are processed like this (listed here in reverse order—
- Collections are generated in the correct order, per the dependency graph.
- Additional Data Cascade operations are applied:
- A separate dependency graph is generated to populate Computed Data,
permalink
,page.url
, andpage.outputPath
in the correct order. Removed in 2.0.renderData
(An undocumented and deprecated feature—use Computed Data instead!) is generated.
- A separate dependency graph is generated to populate Computed Data,
- Templates are rendered in the order generated by the dependency graph (
templateContent
is generated) without layouts applied.- Per the above Note if a template uses another template’s
templateContent
before it has been generated, we defer this template to render in a second pass. - After all
templateContent
’s have been rendered, they are copied into the appropriate collections’ objects. Remember thattemplateContent
in collections does not have layouts included.
- Per the above Note if a template uses another template’s
- Eleventy checks for duplicate permalinks and throws an error if multiple templates are attempting to write to the same output file.
- Templates are then rendered with layouts applied. The previously generated
templateContent
values (without layouts) are re-used here. This content is then written to files on disk.