Change default inputDirectory from '.' to 'src'

[nycki93]

Is your feature request related to a problem? Please describe.

The current behavior of Eleventy for new projects is to treat the entire working directory as the "input directory". This directory contains lots of files that need to be ignored, like node_modules and .gitignore and _site.

That last one is a footgun! See #2410.

I don't think I've ever used Eleventy for anything, big or small, without changing the default input directory. I think that, maybe, the default input directory is wrong.

Describe the solution you'd like

Instead of defaulting to the current directory, it should default to src. In particular, the default input directory should not contain the default output directory.

Describe alternatives you've considered

Currently I add this to every new project I create:

/* eleventy.config.js */
module.exports = function(eleventyConfig) {
    eleventyConfig.setInputDirectory('src');
    eleventyConfig.addPassthroughCopy({ 'static': '/' });
};

Given that this is is a no-brainer thing that every project should have: I think it should be the default.

Additional context

No response

[Ryuno-Ki]

In my case, I call the input directory public but I can adopt src.

[zachleat]

the default input directory should not contain the default output directory.

100% agree with this.

That said: my immediate reaction is that this would be a huge breaking change. It would break every project that didn’t specify an input directory explicitly!

We may have to chalk this one up to “I wish I had done it differently,” unfortunately.

[zachleat]

Let’s add some docs around this to encourage folks into a better path.

I know eleventy-base-blog already uses this, so that goes a long way

Specifically:

• https://www.11ty.dev/docs/
• https://www.11ty.dev/docs/config/#input-directory

[nycki93]

my immediate reaction is that this would be a huge breaking change. It would break every project that didn’t specify an input directory explicitly!

Eleventy 3.0 broke my blog pretty substantially, I had to rewrite my configs, and that was just recently. I think you'd be forgiven for one more breaking change.

Maybe you could have some upgrade notes like "Moving from 3.1 to 3.2: the default input directory has changed to src. If you desire the old behavior, add eleventyConfig.setInputDirectory('.'); to your config file."

[asentris]

I would imagine anyone upgrading to Eleventy 4.0.0 would assume there may be breaking changes according to common SemVer versioning patterns, if you really want to implement this.

[nycki93]

I suppose we could do something like git does, where when you create a new project, it politely suggests that you may want to change the name of the default branch.

[dwkns]

@zachleat

That said: my immediate reaction is that this would be a huge breaking change. It would break every project that didn’t specify an input directory explicitly!

Isn't dealing with breaking changes what major revisions like 4.0.0 are for?

And while I have only this poll on Discord to support this...
I suspect that the vast majority of projects of any complexity already set a input folder as the organisational benefits are so large. This implies that most projects that use the default are more simple and would therefore be easier to update if the change was made.

The update helper for v4.0.0 should be able to detect default input folder use and at the very least give good advice on how to update your project.

[zachleat]

Isn't dealing with breaking changes what major revisions like 4.0.0 are for?

For me semver isn’t just a “change anything you want” as long as you bump a major. I typically weigh the cost/benefit of any breaking change to make sure it isn’t hurting more than it helps (with a mind for cost/benefit being different across both app developers and Eleventy maintainers)

[darthmall]

Personally, I am inclined to agree with Zach on this one: while it is odd, and perhaps regrettable, that the default directories place the output directory inside the input directory, I haven’t yet seen any compelling reasons to change the defaults and break any projects out there that are just using the default input directory.

This directory contains lots of files that need to be ignored, like node_modules and .gitignore and _site.

I’m not quite sure why .gitignore needs to be ignored, and node_modules/ needs to be in your .gitignore anyway, so Eleventy will ignore node_modules/ unless you explicitly opt out of this behavior. And as far as _site/ and #2410 goes, I have been unable to reproduce the issue of having addPasthroughCopy("**/*.jpg") re-copy JPEGs in _site/. As far as I can see, passthrough copy does the right thing and ignores the contents of _site/. Additionally, if you have your project in Git, you will want _site/ in your .gitignore anyway, which would cause Eleventy to ignore it and thus keep passthrough copy from looking for files in there explicitly.

Off the top of my head, the only file I can think of that would typically be in a project and need to be added to .eleventyignore is a README.md file.

I suspect that the vast majority of projects of any complexity already set a input folder as the organisational benefits are so large. This implies that most projects that use the default are more simple and would therefore be easier to update if the change was made.

If it is the case that complex projects change the input directory, then they won’t benefit in any way from a change to the defaults. They might choose to remove any settings that duplicate the new defaults, but that doesn’t seem like a huge win to me.

Meanwhile, any projects that are using the current defaults will have to “fix” their projects when they upgrade — either by adding settings to keep ./ as their input directory, or move everything to the new default locations. I think there ought to be significant, tangible benefits to justify doing this to people. Even if these projects are “more simple” (an assumption I’m not sure you can make based on the question “do you use the default input directory or change it to src/?”), I’m not sure that makes it ok to break their projects, even on a major version increase. One of Eleventy’s strengths is how few breaking changes have been made across all versions. It makes maintaining an Eleventy site much more pleasant.

Making a change to the defaults most benefits people starting new projects, as existing projects already have the configuration in place to make their projects work. But again, I don’t think I’ve seen any clear explanation of the tangible benefits of this change. I’ve made projects with a variety of configurations for Eleventy’s directory structure, including just sticking with the defaults, and I haven’t really found any differences beyond an aesthetic preference for how my project is organized.

[nycki93]

I wasn't aware that eleventy already uses your .gitignore! That's unexpected behavior but probably the right call in many cases. I'll try reproducing the site-inside-site thing again later but if that's no longer an issue then I agree, leave the current default behavior but make it clear in the docs that it can be changed.

[zachleat]

Preview of getting started guide (with a content directory) https://11ty-website-git-eleventy-3955-11ty.vercel.app/docs/

[zachleat]

Added some additional copy to https://11ty-website-git-eleventy-3955-11ty.vercel.app/docs/config/#input-directory

[dwkns]

I understand the reluctance, it is a big change. I'm still on the other side of this, but it's not a hill I'm going to die on 😄.

Just for reference if this issue comes up again (from discord)...

[dwkns]

@zachleat Another thought on this, and a possible way to move it forward and retain backwards compatibility.

In version 4.0

If input is set in config use that — no change.
If a src, source or input directory exists use that —the assumed & recommended default in the v4.0.0 documentation.
If they don't exist default back to . —display a compatible mode message to the console.

That way going forward over time we move to a source directory as default, but don't break backwards compatibility. Maybe depreciate . in v5.0.0 or later (or not).

There would be an (fairly unlikely to occur) issue if someone has a project using . as the input directory but also has a src, source or input directory, but it would just be a matter of adding input: '.' to the config to fix.

Could that work?

[zachleat]

Moving this to the enhancement queue per https://www.11ty.dev/blog/github-issues/