Liquid relative includes on 1.x are relative to the calling file, not the _includes folder

[Liam Bigelow]

Describe the bug
In 0.12.1, a site/index.html file containing {% include './test' %} will load site/_includes/test.liquid
In 1.0.0-beta.7, a site/index.html file containing {% include './test' %} will load site/test.liquid

Unless I've missed it mentioned somewhere, this seems like an undocumented breaking change for 1.x?
(I presume this is an underlying change to liquidjs rather than eleventy specific logic)

To Reproduce
Steps to reproduce the behavior:

Using the file structure:

test.liquid
index.liquid
_includes
    ...

See that:

• 0.12.1: index.liquid should reference the file via {% include '../beep' %}
• 1.0.0-beta.7: index.liquid should reference the file via {% include './beep' %}

Expected behavior
Expecting either matching behavior on 1.0.0-beta.7, or an explicit note about the change so the new logic can be relied upon

Environment:

• OS and Version: Reproduced on Windows and MacOS
• Eleventy Version: Contrasting between 0.12.1 and 1.0.0-beta.7

[Zach Leatherman]

Related: #1995

[Zach Leatherman]

I ran some tests and I can confirm, given an index.liquid with:

1.0

{% include "./test.liquid" %} will look in:

1. ./test.liquid
2. ./_includes/test.liquid

{% include "test.liquid" %} (without the ./) will look in:

1. ./_includes/test.liquid
2. ./test.liquid

0.x

{% include ./test.liquid %} will look in:

1. ./_includes/test.liquid
2. ./test.liquid

{% include test.liquid %} (without the ./) same behavior as above

1. ./_includes/test.liquid
2. ./test.liquid

So, yes it did change as a result of #1995—you’re right! But thinking through it, I think this order of include lookups is more accurate. I’ll make sure to put this on the release notes for 1.x

[Liam Bigelow]

Perfect, the new logic does seem more correct.

There does seem to be an additional change here, though.

0.x

{% include ../test.liquid %} in /src/site/index.liquid will look for:

1. /src/site/test.liquid
2. /src/test.liquid

1.0

{% include "../test.liquid" %} in /src/site/index.liquid will look for:

1. /src/test.liquid
2. /src/site/test.liquid 👈 This one doesn't seem to match.

---

Put another way, if I have the folder structure

index.liquid
test.liquid
_includes
    ...

Those lookup rules mean that {% include "../test.liquid" %} should find the include on its second try (../test.liquid from the perspective of the _includes folder), but instead I see

ENOENT: Failed to lookup '../test.liquid' in: "_includes,.", file:./index.liquid

[Liam Bigelow]

cc @zachleat — just in case this was overlooked. Not critical.

[Zach Leatherman]

@bglw Ah, that’s a good callout. I think this is okay but we can reevaluate if other folks want to push back on it

[Liam Bigelow]

@zachleat Hmm, looking back at it I wonder if some change should be made here. If not to the logic, to the error message.

The following line would be confusing to a developer if hit:

ENOENT: Failed to lookup '../test.liquid' in: "_includes,.", file:./index.liquid

Since it's explicitly saying that it looked for ../test.liquid in _includes, which it didn't.

Either it should look in that location, or it should only say Failed to lookup '../test.liquid' in: "."