JavaScript heap out of memory error when building Eleventy site

[creative42]

Describe the bug
When running npx eleventy --serve to build and serve my site locally, I get this error:

To Reproduce
Steps to reproduce the behavior:

1. Clone my test repo from https://github.com/creative42/myblog.git
2. Run npm i to install
3. Run npm run serve (an alias I have in package.json for the above command)
4. Be patient - it starts to run, pauses for a while, then displays the error above.

Expected behavior
Site is able to build and serve the content locally without issue, under http://localhost:8080

Environment:

• OS and version: Windows 10
• Eleventy version: 0.12.1

Additional context
When I started to build this site, the compilation process ran fine - it seems that a change or addition of something within the repo has caused this error to appear in the last 1-2 days. I've tried several things to fix this issue, but so far nothing has worked:

• Copied files over to a new folder and reinstalled from scratch;
• Increased the --max-old-space to 8192MB as per #695;
• Tested the same files and build process on a Linux machine using Linux Mint 20.2;
• Tested build process in a separate Git Bash window (I normally use VS Code with a Git Bash plugin);
• Tried removing JSON files to see if this had any effect (as per comments seen in GitHub issues);
• Monitored memory usage when build / serve processes running: both went to about 2.2GB before falling over with the error.
• Tried reinstalling the site having removed node_modules folder.

What is odd though is that my site is not large - I have approx 25 files (excluding node_modules folder), so should compile very quickly; when I started, this was indeed the case. I suspect it's gone over a tipping point somewhere, but I've seen comments from people who have significantly larger quantities of files in their Eleventy sites, and are still able to compile OK.

[Peter deHaan]

Fun! Very subtle bug, see creative42/creative42.github.io#1

Basically, your /_includes/layouts/post.njk has this frontmatter:

---
layout: layouts/post.njk
---

So the layout file extends itself, putting you into an endless loop. Changing that to "layouts/base.njk" gives me the following output when running npm run build:

npm run build

> myblog@1.0.0 build /private/tmp/myblog
> eleventy

Writing www/posts/post1/index.html from ./src/posts/post1.md.
Writing www/posts/post3/index.html from ./src/posts/post3.md.
Writing www/posts/post4/index.html from ./src/posts/post4.md.
Writing www/posts/my-second-post/index.html from ./src/posts/post2.md.
Writing www/contact/index.html from ./src/contact.njk.
Writing www/index.html from ./src/index.njk.
Writing www/about/index.html from ./src/about.njk.
Writing www/archive/index.html from ./src/archive.njk.
Writing www/404/index.html from ./src/404.md.
Writing www/1/index.html from ./src/index.njk.
Wrote 10 files in 0.16 seconds (16.0ms each, v0.12.1)

Note: your output might be slightly different. I moved all the relevant files into a "src/" subdirectory and had to recreate the missing .eleventy.js file with the following:

const eleventyNavigationPlugin = require("@11ty/eleventy-navigation");
const dateFns = require("date-fns");

module.exports = function(eleventyConfig) {
  eleventyConfig.addPlugin(eleventyNavigationPlugin);
  eleventyConfig.addFilter("htmlDateString", (date = new Date()) => dateFns.format(date, "yyyy-MM-dd"));
  eleventyConfig.addFilter("readableDate", (date = new Date()) => dateFns.format(date, "MMM d, yyyy"));

  return {
    dir: {
      input: "src",
      output: "www",
    }
  };
};

[creative42]

Thankyou @pdehaan for your help - that was a good spot! I can at least now get it compiling properly :-)

I had played with the site since posting this issue, and was beginning to think something was amiss with how I had set up the posts part - adding the 4 markdown files and the posts.json file caused the problem, but removing them meant it would compile. The site is now runinng, although it should display a list of posts on the homepage; this has stopped working, and will be my challenge for the rest of this afternoon!

[Aleksandr Hovhannisyan]

A naive solution is for 11ty to throw an error in a template layout whenever its front matter specifies itself as the layout. But there may be situations where there is a more complex cycle, like a => b => c => a. So we might need to create a graph of the layouts and detect cycles. Although I wonder if this is worth the effort.

Edit: If layout chains are arrays, like [a, b, c, a], the solution may be simpler: throw an error if the array contains duplicates.

[Zach Leatherman]

Howdy y’all, there are a few issues to organize here so just to keep things concise I am opening #2360 to coordinate this one. Please follow along there!

[Zach Leatherman]

2.0.0-canary.9 shipped with pagination improvements!