Expand virtual template support to includes

[kfranqueiro]

Is your feature request related to a problem? Please describe.

I realize that virtual templates are currently supported for standard files and for layouts, but it seems that they don't otherwise work for files under the includes directory - i.e., any attempt to {% include %} a virtual template fails to find it.

Describe the solution you'd like

I'd like to be able to define virtual templates via addTemplate with file paths under the includes directory, and have template engines pick them up. (I'm using Liquid but realize this might have applicability across multiple engines...)

Describe alternatives you've considered

I attempted to pass { templates: ... } through setLiquidOptions instead, but that didn't seem to work, either. I'm not sure if I'm misunderstanding that feature or if it has side effects though.

Additional context

No response

[btrem]

I've wanted something like this for a long time. It would be useful for plugins to offer bits of code that could be inserted in a layout. ATM I'm writing js template strings, but that can be pretty tedious.

[LeaVerou]

+1, came here to suggest the same thing. I thought that's what addTemplate() was supposed to do, so I've spent hours today trying to figure out the right way to specify virtualPath so the template would be picked up. 😢

[cristovaov]

+1 too, I also thought I could add a virtual template and do an {% include "_includes/virtual-partial.njk" %}.

If this can be implemented for the addTemplate function or with a new config function that'd open up great templating powers.

[tylersticka]

I tried to do this today to include some static assets from a separate package, was a little confused since the documentation includes a layouts example in the _includes directory! Would definitely love this feature. 🫶

[m4rrc0]

Would love to use this as well!

Here is my current workaround for my specific use case, which is:

1. I want to have fallback partials in a directory outside of the input dir
2. I use Nunjucks

I am doing this in my eleventy.config.js:

import Nunjucks from "nunjucks";

export default function (eleventyConfig) {
  let nunjucksEnvironment = new Nunjucks.Environment([
    new Nunjucks.FileSystemLoader(`${INPUT_DIR}/${PARTIALS_DIR}`),
    new Nunjucks.FileSystemLoader(`fallback/_partials`),
  ]);
  eleventyConfig.setLibrary("njk", nunjucksEnvironment);
}

Note: The paths here are relative to your config file I believe. Note 2: From my (very shallow) testing, it seems this is the right order to provide fallback includes. If a matching file exists in the first directory it will be used instead of a matching one in the second directory.

So far it seems to be compatible with everything else in my (rather complex) config and setup... But I have to admit I don't exactly know the possible side effects of defining the Nunjucks Environment by hand like that. Here is the 11ty docs about this feature.

[LeaVerou]

Here is my current workaround for my specific use case, which is:

1. I want to have fallback partials in a directory outside of the input dir

This is actually a feature request I've been meaning to file for a while: the ability to have multiple directories for input, data, includes, layouts. I have to jump through tremendous hoops to do this today.

[m4rrc0]

@LeaVerou I have also wanted this feature for a long time.

Virtual templates finally provide a handy-ish way to do this (almost). I have got this plugin (not published on npm yet but apparently I should) with this kind of usage to help me 'populate' my input dir with any number of other directories having the same folder structure. Files actually present in the input dir are not added, making it effectively a fallback mechanism for non provided content.

The plugin relies on virtual templates though so it does not work for includes.

And the ability to have multiple directories for input, data, includes, layouts would still be my preferred option.