-
-
Notifications
You must be signed in to change notification settings - Fork 471
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Mismatches between explicit and extensionless layout declarations causes quirks when running eleventy with --serve
#3187
Comments
Did you see this? https://www.11ty.dev/docs/layouts/#omitting-the-layouts-file-extension We did try to change this default at one point but it was too painful for folks. |
@zachleat Yep! I've gone through that part of the documentation and I understand that there's a difference in functionality when the template extension is dropped (matching all possible layouts, vs matching a single layout with an explicit file extension). What I didn't expect was that unexpected things can occur when 2 templates refer to a layout with and without the file extension, which I guess "It is ambiguous if you have multiple layout files with the same name and different extensions (e.g. mylayout.njk and mylayout.liquid)." sort of calls out? In my case live-reload wasn't updating my pages after making a change and my fix was to go through my entire project and enforce consistent use of extensions in all my layouts. For good measure I also added I also tested the inverse: removing all extensions from layout calls and the live-reload issues also resolved themselves when doing things that way too. Maybe all that's needed is to supplement the part of the documentation quoted above with something like:
|
Operating system
macOS Sonoma v14.2.1
Eleventy
2.0.1 (also reproducible on 3.0.0-alpha4)
Describe the bug
This bug was a nasty one to stumble upon and took me a while to pin down where it was stemming from. At first I thought it was a WebC issue, but it turns out it affects other template types too and is probably why extensionless layout support was intially removed. Nevertheless, I'm raising this issue and can also open a pull request on the documentation to document what I think may be a common pitfall.
The gist of this bug (or perhaps intended behavior) is that when template
layout
keys reference the same layout, but one file uses the extension explicitly and the other doesn't. While--serve
ing, the template that has the explicitly declared extension won't be rebuilt when changes are made unless the dev server is restarted.UNLESS...there's a directory data file that defines the same layout with or without an extension, if there is, then the declaration of that layout blocks any file from being rebuilt that doesn't follow it's convention. In other words: once a directory data file is introduced that uses/doesn't use the file extension for a layout that sets the standard for all other files using the same layout. Furthermore, if there are files that are in a directory that don't have directory data files in them they can also be blocked from getting rebuilt.
Reproduction steps
I've included a reduced test case for anyone interested to play around with. Some things I've tried to get reproducible results (although some of these might be inaccurate, I don't know a lot about Eleventy's internals to guarantee whether this behavior aligns with what's expected)
eleventy --serve
Expected behavior
Given the complexity of attempting to debug the behavior going on here when there's mismatched layout declarations, I'm not quite sure what the expected behavior should be. Perhaps an error warning that gets thrown if things are mismatched? Or maybe something added to the documentation that says that if you're mixing extensions vs extensionless layout definitions all bets are off when trying to determine why live reload isn't working.
Either way, being consistent with extensions in layouts vs leaving them out seems to be critical in order to get Eleventy to run correctly.
Reproduction URL
https://github.com/noelforte/11ty-webc-layouts-rtc
Screenshots
No response
The text was updated successfully, but these errors were encountered: