Layout path issues since 2.0.0.19 - You’re trying to use a layout that does not exist: default (undefined)

[yhorian]

Operating system

windows 11

Eleventy

2.0.0.19 or 2.0.0.20

Describe the bug

Not present ins v2.0.0.-canary.18

[11ty] Problem writing Eleventy templates: (more in DEBUG output)
[11ty] You’re trying to use a layout that does not exist: home (undefined) (via Error)
[11ty]
[11ty] Original error stack trace: Error: You’re trying to use a layout that does not exist: home (undefined)
[11ty] at TemplateLayoutPathResolver.getFullPath (F:\HTML\eleventy-debug\node_modules@11ty\eleventy\src\TemplateLayoutPathResolver.js:102:13)
[11ty] at new TemplateLayout (F:\HTML\eleventy-debug\node_modules@11ty\eleventy\src\TemplateLayout.js:22:7)
[11ty] at Function.getTemplate (F:\HTML\eleventy-debug\node_modules@11ty\eleventy\src\TemplateLayout.js:47:18)
[11ty] at Template.getLayout (F:\HTML\eleventy-debug\node_modules@11ty\eleventy\src\Template.js:127:37)
[11ty] at Template.getData (F:\HTML\eleventy-debug\node_modules@11ty\eleventy\src\Template.js:381:25)
[11ty] at async TemplateMap.add (F:\HTML\eleventy-debug\node_modules@11ty\eleventy\src\TemplateMap.js:64:16)
[11ty] at async Promise.all (index 0)
[11ty] at async TemplateWriter._createTemplateMap (F:\HTML\eleventy-debug\node_modules@11ty\eleventy\src\TemplateWriter.js:257:5)
[11ty] at async TemplateWriter.generateTemplates (F:\HTML\eleventy-debug\node_modules@11ty\eleventy\src\TemplateWriter.js:294:5)
[11ty] at async TemplateWriter.write (F:\HTML\eleventy-debug\node_modules@11ty\eleventy\src\TemplateWriter.js:341:23)
[11ty] Wrote 0 files in 0.09 seconds (v2.0.0-canary.20)

This is a reproduced version, first noticed using the latest build on my own pug templated blog when it refused to find a default layout.

Reproduction steps

1. Clone a template. I used https://github.com/jeremydaly/eleventy-tailwind-template as it had no eleventy plugins.
2. Install latest build, Change it to "@11ty/eleventy": "2.0.0-canary.20" in package.json.
3. npm install
4. npm run start
5. Throws error, cannot find layout referenced.

Expected behavior

It should be able to find the layouts, matching the layout name regardless of extension used.

Reproduction URL

https://github.com/yhorian/eleventy-debug

Screenshots

No response

[pdehaan]

See #727 (comment) for a fan theory:

Possibly related to #1924 (assuming "base" isn't a layout alias; although I didn't remember seeing that alias in your config file).
11ty.dev/docs/layouts/#omitting-the-layouts-file-extension has more context and a way to reenable layout resolution (and why it probably isn't a good idea).
I'd try changing it to "base.liquid", or creating a layout alias in your config file.

[pdehaan]

module.exports = function (config) {
+  config.addLayoutAlias("base", "base.njk");
+  config.addLayoutAlias("home", "home.njk");
+  config.addLayoutAlias("sitemap", "sitemap.njk");

npm run build

> [email protected] build
> npx @11ty/eleventy && tailwindcss -i _site/css/styles.sass -o dist/css/styles.css

[11ty] Writing dist/sitemap.xml from ./_site/sitemap.md (njk)
[11ty] Writing dist/subpage/index.html from ./_site/subpage.md (njk)
[11ty] Writing dist/index.html from ./_site/index.md (njk)
[11ty] Wrote 3 files in 0.06 seconds (v2.0.0-canary.20)
Browserslist: caniuse-lite is outdated. Please run:
  npx browserslist@latest --update-db
  Why you should do it regularly: https://github.com/browserslist/browserslist#browsers-data-updating

Done in 78ms.

[yhorian]

Thanks, the documentation does point to this being on purpose but what may not be intended is that it will break most existing sites if it goes out as a stable build. Including many of the starters.

Speaking for myself, fuzzy logic and the ability to use any templating language was what made eleventy stand out from alternatives such as Hugo. It meant I could experiment more readily and scavenge more broadly for code to play without spending time adapting it. I believe Eleventy's flexibility is one of its strongest USPs as well. But I'll leave whether trading that for speed is worth it up to the experts.

[zachleat]

We’ll keep the escape hatch around for folks that run into this issue. It should be a very easy fix for folks: https://www.11ty.dev/docs/layouts/#omitting-the-layouts-file-extension

I do think the aliasing method @pdehaan mentions above is better though!

But I’ll keep monitoring the issue tracker to see how many folks run into it. I’m open to reverting but I do think this is an improvement.

The old way required potentially 10 or 11 file system checks and the ordering was ambiguous. If you have a base.liquid and base.njk—which does it select? I think for this specific case it’s better to be explicit, especially as we improve incremental builds.

[flaviotordini]

I really like the extensionless layout name. They allow for flexibility in reimplementing a template with a different tool. Maybe the wrong choice is having a large templateFormats list by default. templateFormats should be empty and set by the user. Moreover resolved filenames could be cached to avoid filesystem checks.

[zachleat]

Restoring this feature: #2708

[paulshryock]

what may not be intended is that it will break most existing sites if it goes out as a stable build.

But isn't the point of a major SemVer release that there will be known breaking changes? I see breaking changes in 2.0.0 as expected -- and welcome, if they come with significant improvements.

[zachleat]

For sure @paulshryock—I don’t think this one quite meets the cost benefit requirements of a breaking change yet!

My plan is to package this early in 3.0.