Allow top level directory specific data files

[zachleat]

Global data files allow scoped global data to be set, but how do I set a permalink structure for the entire project?

_data/myGlobal.js scopes to myGlobal.*

I want to set a permalink structure in ./myProject.11tydata.js that cascades to all templates.

One wrinkle could be what the file name convention would be (or if this matters at all).

If my project parent directory is myProject then we could look in ./myProject.11tydata.js, ./myProject.11tydata.json, and maybe ./myProject.js (probably not this one, too much potential for conflicts?)

Related: https://www.11ty.io/docs/data-template-dir/

[zachleat]

This repository is now using lodash style issue management for enhancements. This means enhancement issues will now be closed instead of leaving them open.

The enhancement backlog can be found here: https://github.com/11ty/eleventy/issues?utf8=%E2%9C%93&q=label%3Aneeds-votes+sort%3Areactions-%2B1-desc+

Don’t forget to upvote the top comment with 👍!

[remy]

It feels like a step towards this, and stepping around the naming issue, would be to define it in the config.

Otherwise, can I propose _default. as a prefix? You've already got an hint that _ prefix means "system" and not user land code (i.e. _includes, _data). "default" meaning it can be overridden.

I'm familiar with the code, but would be happy to take a shot.

[zachleat]

Hmm!

(I don’t think this is the right place for an addition to Layout aliasing, but I do just want to make sure you know that it exists: https://www.11ty.io/docs/layouts/#layout-aliasing)

Also related, configuration API to set global data: #184

However, I’d prioritize this issue over those two others I just mentioned. More value here, I think.

For the naming question, I was tempated to go with the existing pattern of using the parent folder name (even though, in this case, it’d be the project folder name). But when I think about it a bit more I think this pattern will cause issues—specifically with how GitHub repos are set up—if you check out a project from GitHub and don’t name the parent folder correctly the project wouldn’t build right, which is very bad.

So I think you’re on the right track. Maybe ./.eleventy.11tydata.js and ./.eleventy.11tydata.json to sort of match up with the default config filename?

[zachleat]

Wow GitHub comments are out of order here—that‘s confusing. https://www.githubstatus.com/ seems all nominal though ¯_(ツ)_/¯

[Ryuno-Ki]

I don't the issue with the naming …
Could you outline it with a folder structure and the mapping to the URLs?

What files are conflicting?

[zachleat]

Consider this repo: https://github.com/11ty/eleventy-base-blog

My original comment was proposing that we tie into /eleventy-base-blog.11tydata.js and /eleventy-base-blog.11tydata.json for this.

However, if someone checks the repo out, there is no guarantee as to what they’ve named the parent folder (as it is not enforced by the git project structure). They could have cloned into anything. We shouldn’t couple this or enforce constraints that introduce variability based on where you’ve cloned the project.

So, a standard /.eleventy.11tydata.js and /.eleventy.11tydata.json would work better.

[Ryuno-Ki]

Ah, okay, I think, I see what the issue now.
Say, I cloned the repo via git clone https://github.com/11ty/eleventy-base-blog.git my-first-blog.
Then the created directory would be my-first-blog.

Now, I want to have the files deployed on https://example.com/me/, i.e. I need to change the permalink from my-first-blog to me (otherwise it would end up in https://example.com/my-first-blog/).
For GitHub pages even „worse”, since the structure is <mygithubusername>.github.io/<githubrepo>.

So we can't rely on eleventy-base-blog.
But .eleventy.11tydata.js(on) would be „hidden file”.

What we would need is a pendant to _config.yml (Jekyll) or config.toml (Hugo) or harp.json.

My personal take: This is something, a postreceive git hook should deal with.
From my experience with harp, I've learned that on rendering, it wiped the target directory (I'm not kidding - luckily my hoster makes regular backups, so I „only” lost one day worth of data).
So I'd render it to a temporary directory than copy it over to the target destination.

So you could defer to packages like github-pages (seems dead) for the deployment.

[remy]

I'm inclined to echo @Ryuno-Ki's concerns about using a hidden file for defaults. I wonder if it's a personal preference, but I've never been keen on configuration being in hidden files (but that's the standard-ish devworld we have). But adding defaults into a hidden file bears some careful consideration.

I think there's a strong pro for using the same convention of .eleventy.11tydata.js(on), but I'm wary there's an equal con of making it (effectively) hidden.

I get why there's a period - to avoid any potential conflicts with user authored code.

Though a counter argument in favour of what @zachleat is saying: if the .eleventy is a design principle of the system, then it's documented (at least in theory) and that's the right thing to pick for naming.

hashtag name is hard…

[Ryuno-Ki]

Linux History: How Dot Files Became Hidden Files - in case you are interested why we have hidden files in the first place :-)

[kleinfreund]

I would do it like this:

• Treat all *.11tydata.js (or *.11tydata.json) files as global data files. If we only want to allow one global data file, it should be eleventy.11tydata.js (or eleventy.11tydata.json).
• Scope all global data files to eleventy. (or site.? project.?) to distinquish between regular data files.

I never realized this when working with Eleventy, but the .eleventy.js file is indeed a hidden file in Linux OSes. This is not ideal and could lead to confusion for new users. For example: “I’m sure I created the file, but I can’t find it in the finder/file explorer!”. For future features, I would prefer to avoid using a dot prefix for file system objects.

[ahl]

@zachleat I'd love to see this happen; would you accept a PR?

[zachleat]

Some work for this is happening in #935 although I am arguing that that one is a bug and this one is a enhancement 😇