Check if includes dir is relative to current dir or input dir

[zachleat]

Currently is relative to input directory, which is confusing. See #60.

It’s unlikely we’ll be able to wholesale change this, but we can at least check to see if the directory exists before we choose.

[zachleat]

The following image from #60 illustrates it best:

[kleinfreund]

In the future, will it be possible to have the include directory reside outside of the input directory?

[zachleat]

Hmm, this is a good question. This will lead to some guessing which would cause some weird edge-cases, I think. If { input: "src", includes: "_includes"} and folders exist at ./src/_includes and ./_includes, we could throw a warning I suppose! If only one of those folders exists (or none) we could proceed without issue.

I kinda wish I had made it work root-relative from the start, but here we are.

[kleinfreund]

Maybe you can get input/data on what current users prefer? It should be possible to somehow transition to root-relative dirs without breaking things for existing users immediately.

In the example you provided, where both ./src/_includes and ./_includes exist, the default would be ./src/_includes (dir.input-relative) during the transition time. Later, dir.includes would default to be root-relative and only ever be dir.input-relative if dir.includes doesn’t exist in the root.

[zachleat]

This repository is now using lodash style issue management for enhancements (see https://twitter.com/samselikoff/status/991395669016436736)

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+

[wesruv]

I don't know if this is bad practice for static site generators, but I want to be able to include any *.njk file in any other *.njk file.

I'm trying to create a simple component library/style guide, and forcing an _includes folder means the actual component markup has to live along side of my layouts.

What I'd like:

|-- templates/
|   |-- _includes/
|   |   `-- < behind the scenes styleguide only stuff >
|   |-- components
|   |   `-- < components that output their own page and macros for importing elsewhere >
|   `-- pages
|   |   `-- < pages that import all sorts of components >
|-- scss/
|   `-- <sass stuffs>
|-- es6/
|   `-- <es6 stuffs>
|-- static-dependencies/
|   `-- <static webfonts, images and libraries I'm using>
|-- static/
`   `-- <output dir>

Correct me if I'm wrong, but I think what I have to do with the current setup is build the page structure inside of templates, but have all the relevant markup for components buried in templates/_includes and my components/* pages are basically stubs.

Unless I'm missing something?

Upvoting issue.

[wesruv]

Actually appears if I leave set dir.includes to "" it uses the dir.input.

module.exports = function(eleventyConfig) {
  return {
    templateFormats: [
      "njk",
    ],
    dir: {
      input: "templates/",
      includes: "",
      output: "static",
    },
  };
};

Hopefully this isn't a mortal sin or something? It was confusing as hell to figure out, it would have made more sense to me if includes was from the root, or if includes took "." or "./" as values.

[shreyasminocha]

In the future, will it be possible to have the include directory reside outside of the input directory?

I would love to have that option.

Currently I have:

.
├── layouts/
│   └── …
├── partials/
│   └── …
├── mixins/
│   └── …
├── static/
|   # thanks to #452, these no longer have to be in the root
|   ├── css/
|   ├── js/
|   └── …

# pages and collections in the root :(
├── committees/
├── …
├── index.pug
├── …
├── sitemap.xml.pug
└── updates.md

# and of course, config etc files
├── now.json
├── package.json
└── …

But I don't want to have all pages and collections in the root directory alongside dotfiles and other config files. I want them all to be in a directory of their own at the same level as layouts, partials, or mixins.

.
├── layouts/
│   └── …
├── partials/ # includes
│   └── …
├── mixins/
│   └── …
├── static/
|   # thanks to #452, these no longer have to be in the root
|   ├── css/
|   ├── js/
|   └── …

# pages and collections neatly tucked away in a dir of their own 🚀
├── pages/
|   ├── committees/
|   ├── …
|   ├── index.pug
|   ├── …
|   ├── sitemap.xml.pug
|   └── updates.md

# and of course, config etc files
├── now.json
├── package.json
└── readme.md

Should this be an issue of its own?

[sonniesedge]

After a long time not building websites I just tried using Eleventy. The need for nested includes instantly confused me and ultimately resulted in a very messy structure with content files living alongside layout files.

A big upvote here for dropping the need for includes and data to live inside input!

Still love it all though! ❤️

[zachleat]

To be clear here (much later)—using .. in includes/layouts/data directory definitions to break out of the input directory is supported!

dir: {
  input: "content",
  includes: "../includes"
}

Works with (at the same level):

• 📁 content
• 📁 includes

[uncenter]

What about adding a new dir.relative option that defaults to true, which means people can opt-in to using non-relative-to-input-dir paths for includes/layouts/data with relative: false? It could eventually be changed to default to false in v4.

[zachleat]

(moving back to the enhancement queue)