Global data filename being `tags.js` throwing error

[tannerdolby]

Describe the bug
When I have a global data file named tags.js in the _data directory, this odd error is thrown:

Problem writing Eleventy templates: (more in DEBUG output)
> entry.data.tags is not iterable

`TypeError` was thrown:
    TypeError: entry.data.tags is not iterable
        at TemplateMap.getMappedDependencies (/Users/TannerDolby/11ty-portfolio/node_modules/@11ty/eleventy/src/TemplateMap.js:109:38)
        at TemplateMap.cache (/Users/TannerDolby/11ty-portfolio/node_modules/@11ty/eleventy/src/TemplateMap.js:278:30)
        at TemplateWriter._createTemplateMap (/Users/TannerDolby/11ty-portfolio/node_modules/@11ty/eleventy/src/TemplateWriter.js:170:28)

It doesn't seem to be caused by any of my local files, so I was wondering if maybe anyone else encountered something like this. The only thing I could think of quickly was that the tags.js filename is replacing some file local to 11ty with the same name. The error is thrown when the tags.js file has content in it and when its completely empty.

To Reproduce
Steps to reproduce the behavior:

1. Go to your _data folder
2. Create a file tags.js
3. Build eleventy (eleventy)
4. See error

Expected behavior
A clear and concise description of what you expected to happen.
I expected the tags.js filename to be fine as a global data file. I didn't think there were any reserved filenames that couldn't be used so this made me curious.

Screenshots

Environment:

• OS and Version: [Mac OS High Sierra v10.13.6]
• Eleventy Version [v0.11.1]

Additional context
Add any other context about the problem here.

[pdehaan]

@tannerdolby Works for me, but my tags.js file looks like this:

module.exports = ["one", "two"];

What I think is happening, is that your _data/tags.js global tags object, is conflicting with the 11ty tags frontmatter key.

Per https://www.11ty.dev/docs/data-configuration/

tags: A single string or array that identifies that a piece of content is part of a collection. Collections can be reused in any other template. Read more about Collections.

So, 11ty expects a tags key in your template frontmatter, and then uses those tags to sort things into collections.

Depending on the format of your newly custom _data/tags.js, I'm suspecting it's blowing up because it expects an array (or possibly a single string which it converts to an array somewhere in the bowels of the 11ty engine).

[pdehaan]

This is actually pretty interesting... Here's my project layout:

tree -aI node_modules
.
├── .eleventy.js
├── package-lock.json
├── package.json
├── src/
│   ├── _data/
│   │   └── tags.js
│   └── home.liquid
└── www/
    └── index.html

3 directories, 6 files

The .eleventy.js isn't very interesting:

module.exports = (eleventyConfig) => {
  eleventyConfig.addFilter("objectKeys", Object.keys);

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

My ./src/_data/tags.js looks like this:

module.exports = ["one", "two"];

And my ./src/home.liquid looks like this:

---
title: behold, a title
permalink: /
---

title={{title}}
permalink={{permalink}}
url={{page.url}}
tags={{tags}}

collections={{ collections | objectKeys }}

Now, if I build my project, it will create my ./index.html file with the following:

title=behold, a title
permalink=/
url=/
tags=["one","two"]

collections=["all","one","two"]

So it looks like having a ./src/_data/tags.js is a fallback default for my frontmatter tags value!

And if I add an explicit tags key/value to my ./src/home.liquid file, it uses those values instead of the ones injected by ./src/_data/tags.js:

---
title: behold, a title
permalink: /
tags:
  - a
  - b
---

title={{title}}
permalink={{permalink}}
url={{page.url}}
tags={{tags}}

collections={{ collections | objectKeys }}

And now my generated ./index.html file uses the local frontmatter tags for its tags and collection data:

title=behold, a title
permalink=/
url=/
tags=["a","b"]

collections=["all","a","b"]

Not sure if any of this is by design, or just an unexpected side effect. I think I've read somewhere (docs or issues) about creating a ./_data/eleventyComputed.js global data file to do some magic, but I probably wouldn't recommend using a global ./_data/tags.js because this side effect just feels unexpected and fragile (as you pointed out, if your tags.js data file doesn't return some iterable array):

module.exports = {"one": 1, "two": 2}; // TypeError: entry.data.tags is not iterable

[tannerdolby]

@pdehaan Thank you for the detailed explanation and test!

What I think is happening, is that your _data/tags.js global tags object, is conflicting with the 11ty tags frontmatter key. Depending on the format of your newly custom _data/tags.js, I'm suspecting it's blowing up because it expects an array (or possibly a single string which it converts to an array somewhere in the bowels of the 11ty engine).

I think your right. After doing a bit of testing locally, it definitely was happening because the global tags object was conflicting with _data/tags.js. The data I was exporting from tags.js wasn't an iterable array and the global tags object was attempting to use the global data file to populate the tags object.

So it looks like having a ./src/_data/tags.js is a fallback default for my frontmatter tags value!

Yep! I agree. When I have an iterable array returned from _data/tags.js like:

module.exports = { foo: "bar", buzz: "bazz" } 

My template has tags=["bar", "bazz"]

And if I add an explicit tags key/value to my ./src/home.liquid file, it uses those values instead of the ones injected by ./src/_data/tags.js:

Exactly. So I think we have uncovered that:

1. A global data file with filename that matches an Eleventy global object, like tags will inject the value from module.exports from the data file to the global object during buildtime, but when a tags key is defined in the template those values take higher precedence and are the ones that stick around.
2. Not sure if any of this is by design, or just an unexpected side effect, but probably wouldn't recommend using a global ./_data/tags.js because this side effect just feels unexpected and fragile (as you pointed out, if your tags.js data file doesn't return some iterable array):

[tannerdolby]

not sure if this is deemed ready to close, but having your eyes on it would be appreciated!

CC @zachleat