Extract "default" template languages (Nunjucks, Liquid, markdown) to plugins

[uncenter]

...like the more esoteric templating languages that were moved out of core to plugins with v3, Nunjucks and Liquid should also be plugins - so that I, someone who uses neither of those two (I use Vento), am not installing an extra 3MB every time.

Originally posted by @uncenter in #3587

As suggested by @Ryuno-Ki, opening as a new issue for this discussion.

---

Since Eleventy tries to remain unopinionated, I think moving these template languages to separate plugins in https://github.com/11ty/eleventy-plugin-template-languages would make sense. If it is felt that including (a) default template language(s) is important (i.e. new users, simplified configuration/setup - valid points), I would propose splitting Eleventy into two packages; @11ty/core and @11ty/eleventy, the former being a more barebones scaffolding tool and the latter coming with more defaults and reinforced structure. Just a thought :)

[Ryuno-Ki]

Thank you 🧡

I think, one of the beautiful aspects of Eleventy is the support for multiple template languages (as well as their mix-and-match). This eases the transition from other systems to it (Jekyll using Liquid, Python with Jinja2 which is almost identical to Nunjucks etc).

On the other hand there's this argument that by bundling all those template language engines the package download size goes up.

Splitting it up might be a good strategy. In the past, several pieces have been moved into plugin land.

[boehs]

In regards to forming a core, eleventy has a lot of odd vestigial organs supporting languages like HTML, Markdown, Nunjucks and Liquid inside of what could be considered to be the current "core". This includes but is not limited to stuff relating to the following configuration options:

• setLiquidOptions / addLiquidFilter / setLiquidParameterParsing / addLiquidShortcode
• setNunjucksEnvironmentOptions / addNunjucksFilter / addNunjucksAsyncFilter / addNunjucksShortcode / addPairedNunjucksShortcode / addPairedNunjucksAsyncShortcode / addNunjucksGlobal
• markdownTemplateEngine / addMarkdownHighlighter

all of these functions internally either

• are a thin wrapper for another API
• should be a thin wrapper for another API

There's no great reason why eleventy's core codebase should hold variables that essentially enshrine eleventy's default templating languages first class citizens. Removing all references to stuff like this in the core library and migrating them to a sort of "starter" project ensures that all templating languages have an equally robust plugin API, and improves perf for projects not using the starting stuff.

Example

e.g. in the case of templating language specific filters/shortcodes, migrate to universal filters. If supporting language-specific filters is desirable, a new param can be added to addFilter that scopes it. Thus, addNunjucksFilter could be reimplemented as

// though of course this function shouldn't exist in core, @eleventy/starter may want to implement it
function addNunjucksFilter(name,callback) {
  // third param refers to a given template format's name
  this.addFilter(name,callback,"njk")
}

Details

Conformance to this looks like rg "html|md|njk|nunjucks|liquid" ./src --glob '!Engines/*' returning no results aside from comments

Probably, if I was to do this, I would do the following

1. Remove everything language specific I could identify
2. Attempt to create an external eleventy wrapper that reimplements the functionality I ripped.
3. Refactor the eleventy codebase to account for the newfound simplicity

If nobody else does, I will give this a try n months in the future where n represents when my current workload subsides

[darthmall]

I’m concerned that moving more of Eleventy’s core functionality into plugins creates a barrier for anyone wanting to use Eleventy that is not already familiar with Node — especially people who are relatively new to programming. Batteries included is really helpful for newcomers.

[uncenter]

Did you see my comment about splitting into two packages? That might also sort of exist now with what @zachleat has been doing with multiple bundles for v4 - not sure if this change would fit in what he envisions but maybe a bundle without default template langs?

[darthmall]

That’s certainly a better option than just removing all templating languages from Eleventy, but even so it introduces potential confusion for new users regarding which package they want. And I’m not entirely sure I understand the motivation for this change either. I understand wanting to shrink bundle sizes for libraries that are shipped to browsers to cut down on bandwidth and improve performance, but in the case of dependencies on your local machine, 3mb just doesn’t seem like that big of a deal to me. I feel like I need more context for when eliminating these dependencies is important.

[zachleat]

Per the work in #3858 we could very easily extend the approach we used to publish @11ty/client to publish an @11ty/core package that did not include any template syntax libraries. The @11ty/client package already has separate bundles for Nunjucks and Liquid and Markdown that can be loaded independently on the client (or not at all)

[zachleat]

Converting this one to a Discussion. I think it’s still on the table to decouple these out but this is more of an internals thing as it’s unlikely we’ll remove any of the current default template syntaxes we support moving forward