Virtual templates not triggering a re-build in 11ty 3.0 beta

[scottsweb]

Operating system

Fedora Silverblue 40

Eleventy

3.0.0-beta.2

Describe the bug

Editing virtual templates does not trigger a re-build of the site. Registering them as a watch target doesn't seem to help either.

Reproduction steps

1. Register a virtual template:

    const robotsTemplate = fs.readFileSync(path.resolve('elva/templates/', 'robots.njk'), 'utf-8');
    eleventyConfig.addTemplate('robots.njk', robotsTemplate);

2. Start the dev server npx @11ty/eleventy --watch --serve
3. Edit the robots.njk template and the dev server does not update to reflect the changes. robots.txt is not updated in the browser
4. Add the templates folder to your watch targets:

    eleventyConfig.addWatchTarget('./elva/templates/*');

5. Editing the robots.njk template triggers a re-build as expected, but the content is not refreshed in browsers.

The full project I am working on can be found in this branch:

https://github.com/scottsweb/elva/tree/v2

Expected behavior

Virtual templates should be re-built when modified.

Reproduction URL

https://github.com/scottsweb/elva/tree/v2

Screenshots

No response

[zachleat]

Just a small (unrelated) question—is there a reason why you’re using virtual templates AND reading from the file system? Eleventy does this specific task for you without virtual templates!

[scottsweb]

Thanks for the reply @zachleat - hope all is well!

I believe I started down this path because I wanted to begin separating concerns in my starter theme framework.

The starter theme framework exists in a separate folder from the actual theme templates in my version 2.0, which makes tracking updates for people relying on it a little easier.

My "proper" use of virtual templates is being able to generate language specific feeds and manifest files here: https://github.com/scottsweb/elva/blob/v2/.eleventy.js#L94-L99 - I must admit though I am still learning lots of this, so I may not have nailed the implementation yet.

[zachleat]

No worries! I appreciate the clarification!

Definitely agree that this is a bug.

[zachleat]

We can’t use the virtual template’s input path to inform changes here, since you’re loading from the file system manually. So unfortunately we can’t handle this use case automatically (yet?)

Adding an additional option to eleventyConfig.addWatchTarget to facilitate this:

// Shipping with 3.0.0
eleventyConfig.addWatchTarget('./elva/templates/*', { resetConfig: true });

Standard watch targets rebuild but do not reset the configuration file (which is what you’ll need to do here).

At some point we may ship an API to read directly from the file system and handle this use case automatically—stay tuned!

[scottsweb]

Lovely, thank you so much!

[scottsweb]

@zachleat just to follow up here. I believe I went with loading the templates from the filesystem like this as it was the only way I could get the frontmatter to be respected within the virtual template.

This is the header of the robots.njk template referenced above:

---
permalink: /robots.txt
eleventyExcludeFromCollections: true
seo:
  excludeFromSitemap: true
---
{%- if settings.isProduction -%}

... more stuff here

When loading the template from the filesystem the permalink is respected. When loading it "normally" the robots file ends up as an index file in /robots/.