Globals

Baseline registers a handful of global data keys and a few Nunjucks globals. Most of them are reference targets you can read in templates; the rest are reserved namespaces that keep module-namespaced data from colliding with filters.

_baseline

The plugin's runtime introspection object. Built in three additive merges as the entry point runs. The shape mirrors Eleventy's own eleventy global: identity fields (name, version) at the top level, env for environment signals, with Baseline-specific data (options, features, paths) alongside.

_baseline = {
	name: 'Eleventy Baseline',
	version, // npm package version
	env: { mode, package }, // mode = ELEVENTY_ENV; package = npm package name
	options: {
		// Snapshot of the resolved options object (state.options).
	},
	features: {
		verbose,
		multilang,
		sitemap,
		navigator,
		head: { titleSeparator, showGenerator },
		assets: { esbuild },
		hasImageTransformPlugin
	},
	paths: { input, output, includes, data, assets, public }
};

Top-level identity

Lifted to the top level so they sit alongside _baseline.env and _baseline.features the same way Eleventy's eleventy.version sits alongside eleventy.env. If you used _baseline.env.name or _baseline.env.version previously, those moved to _baseline.name and _baseline.version.

_baseline.env

A note on mode: it reflects ELEVENTY_ENV, not Eleventy's own ELEVENTY_RUN_MODE. The two are different signals: ELEVENTY_ENV is the environment your process started in (development, production, whatever you set), while ELEVENTY_RUN_MODE is what Eleventy is doing right now (build, serve, watch). Baseline uses the former for activation defaults (e.g. navigator on in dev). The latter shows up in the drafts preprocessor.

They have caught people out before; reach for the one that names the signal you mean.

_baseline.options

A snapshot of the resolved options object (state.options). Carries every option Baseline computed after merging your options argument with defaults, in its on-the-wire shape (so multilang, not multilingual; assets.esbuild, not assetsESBuild). Useful for templates and filters that want to behave differently based on what was configured.

If you only need the boolean "is X active?" answer, _baseline.features below is the resolved view. _baseline.options is the raw resolved input.

_baseline.features

Resolved option flags. Reflects what Baseline decided after merging your options argument with defaults.

A naming nit worth flagging: the user-facing option is multilingual, but the resolved state key is multilang (short form). The features object reflects state, so you read _baseline.features.multilang even though you wrote options.multilingual.

_baseline.paths

Resolved directory paths from eleventyConfig.directories. Read-only; useful for filters and shortcodes that need to know where things live on disk.

If you previously used _baseline.assets.input or _baseline.assets.output, those keys moved. They are now _baseline.paths.assets (a directory path) and _baseline.paths.output. The shape changed in the audit; old references will need updating.

_pageContext

A normalised per-page object built at cascade-time and exposed to every page. One sentence here, full surface on its own page: see Page context.

_snapshot

A debugging snapshot populated by the navigator module. Available when navigator is active (default in development). Exposes:

• _snapshot.contentMap - Eleventy's content map at the time the navigator template renders.
• _snapshot.pageContext - every page-context object the registry has built so far.

Read at module-init in templates that want to introspect the build. See the navigator module for the full picture; the navigator template at /navigator-core.html is the canonical consumer.

_snapshot.contentMap is null while the navigator template itself renders, because the template renders before Eleventy emits eleventy.contentMap. Reading _snapshot from any other page sees the populated value.

_navigator

A Nunjucks global, registered by the navigator module. The cross-page read surface for plugin-produced data, shape { nodes, edges, backlinks }:

• _navigator.nodes is the per-page map from the content graph, keyed by URL. Each entry carries identity fields (title, slug, description, lang, locale, date, url, breadcrumbs) merged with extracted fields (excerpt, headings, sections, images). Identity comes from the page's _pageContext; the extracted fields come from the rendered HTML.
• _navigator.edges is a flat array of every link in the graph. Each edge is { internal, from, to, text, rel }. One edge per anchor in each page's extracted root.
• _navigator.backlinks is the target-keyed enriched backlinks map: { targetUrl: Array<{ url, title?, excerpt? }> }. Pre-joined with the source page's title and excerpt so consumers read enriched records directly.

Authors paginate over _navigator.backlinks to generate "what links here" subpages, or read _navigator.nodes and _navigator.edges directly for cross-page features (related-page lists, navigation indices, link audits).

The navigator is both a runtime-introspection surface and the public read surface for plugin-produced cross-page data; the per-page view of the same substrate is on _node, _backlinks, and _outgoing below.

_node, _backlinks, and _outgoing

Three computed cascade keys, populated per page from the content-graph pre-pass.

• _node is the current page's own node from the content graph: identity fields (title, slug, description, lang, locale, date, url, breadcrumbs) merged with extracted fields (excerpt, headings, sections, images). Read it for the page's headings (a table-of-contents source), its own excerpt, or any of the identity fields without re-reading them through the cascade.
• _backlinks is the array of edges where to === page.url: bare edge records, shape { internal, from, to, text, rel }. Each entry names a page that links to the current one and the text of the link. Empty array if nothing links here.
• _outgoing is the array of edges where from === page.url: same shape. Each entry names a page (or external URL) the current page links to.

_backlinks and _outgoing carry raw edges, not enriched records. If you want the source page's title and excerpt for a backlink, read _navigator.backlinks (target-keyed and pre-joined) instead.

Two consumers, two shapes: the per-page keys carry the most local view; the cross-page map carries the enriched, target-keyed view a backlinks-index template needs.

All three keys read through coreContext.runtime.contentGraph via getters, so rebuilds that reassign the underlying graph reference are picked up automatically.

Pages flagged _internal: true (synthetic templates like sitemap XML and schema endpoints) drop out of the graph cleanly, as do pages flagged baselineExcludeFromGraph: true (a graph-specific opt-out for renderable pages that should stay outside the graph: 404s, showcase index pages, anything that should render without self-referencing). eleventyExcludeFromCollections: true is Eleventy's collections opt-out and does not exclude a page from the graph on its own.

A fourth key, _edges, is reserved in INTERNAL_KEYS but no value is currently bound to it. Placeholder for a future per-page or global edges surface.

Reserved-but-empty keys

The entry point reserves additional keys as empty objects:

• _assets
• _head
• _multilang
• _sitemap

They exist so module-namespaced data can merge cleanly without colliding with same-named filters. No module currently writes into them; if you see one of these in a _data dump, it's {} by design.

Together with _baseline, _navigator, _snapshot, eleventyComputed._pageContext, eleventyComputed._node, eleventyComputed._backlinks, and eleventyComputed._outgoing (all populated today) plus eleventyComputed._edges (reserved, currently unbound), that is twelve reserved keys. The full list lives in INTERNAL_KEYS in the entry point. See Internals.

See also

• Plugin entrypoint - where these globals are registered.
• Page context - _pageContext shape.
• Internals - INTERNAL_KEYS and the registry primitive.
• Navigator module - _snapshot, _runtime, _ctx.