More forgiving errors during dev with missing filters

[LeaVerou]

I’ve been using filters extensively. Most of my 11ty projects have an import like:

import * as filters from "./filters/index.js";

and a mass-add statement in the config:

for (let name in filters) {
	config.addFilter(name, filters[name]);
}

If a filter is invalid, 11ty currently throws (and the error message code path is broken, see #3385).
I’d argue that this is not a reason for complete and total failure — a warning should suffice. Something like "Filter foo ignored, as it is not a function".

However, then if filter foo is used anywhere, that would throw. But should it really?

As part of debugging, I often comment out plugins. But that means now their filters produce errors! So temporarily disabling a plugin involves tediously adding stubs like

config.addFilter("foo", content => content);

What if 11ty could do this for any unrecognized filter, and just printed out a warning? Fault tolerance and robustness are generally good API design principles to follow. The main case where you don't want to fail gracefully is when making the wrong assumption could produce data loss (see #3373), but that doesn’t seem to be the case here.

[zachleat]

I bet we could get away with a template-syntax independent implementation of this feature using Proxy. I’d imagine folks might want it to operate this way during dev but not in a full production build, too.

[zachleat]

By default this repo closes enhancement request issues and places them in a queue for folks to upvote. We do this to avoid a large build-up of open issues. We got this idea from the lodash project.

Don’t forget to upvote the first comment with 👍 to register your vote! You can view the current enhancement backlog.