Reduce size of dependency graph

[Krinkle]

Is your feature request related to a problem?
Yes, I'd like Eleventy to be easier to audit and trust as an executable that one would let produce HTML to serve in production to end-users. For those who care, this is not the only part that matters of course. You'd probably want to do some spot-checking on the output and have CSP in place. But I don't think treating the generator as an inherently untrustable/unreviewed black box is reasonable.

I believe the Eleventy code base and community itself is great, fairly auditable, and as a group of maintainers I think the GitHub and npm organisations of Eleventy can also be trusted to oversee itself and not be easily compromised in a way that wouldn't be quickly noticed. However, I don't think I as a user can say the same about all transitive dependencies.

Describe the solution you'd like
For Eleventy to drastically reduce the number of dependencies and publishers required to be trusted for non-dev installations of the @11ty/eleventy package. And ideally for the handful of dependencies that remain (10? 20?) to have been audited by the maintainers of Eleventy, and to have been determined to be responsible, disciplined, well-maintained, and responsive. Perhaps we could even adopt a set of principles around this, such as how Puppeteer (link) and QUnit (link) have done.

This would likely be a long-term effort and include collaborating with maintainers of upstream dependencies. I've done this before and would love to help.

Describe alternatives you've considered
Jekyll 4.1.1 currently has 26 dependencies. Most of which are in turn are dependency-free and well-known standalone packages that solve core problems.

Eleventy 0.9.0 had 555 dependencies.
Eleventy 0.11.0 currently has 372 dependencies. This includes well-known, disciplined, and standalone packages that solve core problems such as mustache and liquid, but also many many others.

This seems to be heading in a good direction, almost a 50% reduction compared to two years ago. If this was part of an existing effort with a tracking issue, feel free to close/merge, I'd love to help out there instead. (I did search but found none.)

Additional context

I'm probably a boring grumpy person, but I care and want to see Eleventy become even more awesome!

[zachleat]

I think this is a fair point of discussion and I like it. A lot of overlap with #1103 too!

[Krinkle]

Package is-buffer is no longer needed, used via condense-newlines ⇨ kind-of:

• Removed from kind-of@5.
• Awaiting updating condense-newlines ⇨ kind-of in Update to kind-of 5 to remove is-buffer dependency jonschlinkert/condense-newlines#3.

Package yargs, is-buffer and uglify-js no longer needed, used via pug:

• pug ⇨ pug-filters@3.1 ⇨ uglifyjs@2 ⇨ yargs ⇨ cliui ⇨ kind-of.
• uglify-js@3 has replaced the entire yargs subtree commander in mishoo/UglifyJS@ec443e4, and subsequently phased out all need for external dependencies, removing source-maps (handle source-map operations internally mishoo/UglifyJS#3754), and commander (parse command line internally mishoo/UglifyJS#3961).
• pug-filters 4.0 has removed the need for uglify-js alltogether in pugjs/pug@a941dec
• Awaiting pug to use pug-filters 4.0 in Considering updating the dependencies to fix vulnerability issue? pugjs/pug#3225.

Package mkdirp no longer needed, used via js-beautify:

• Awaiting Use native mkdirSync instead of 'mkdirp' package beautifier/js-beautify#1833.

Subtree of chokidar is quite large, used via nunjucks:

• Considering replacement with much simpler https://github.com/yuanchuan/node-watch.
• See Revisit the watch option and chokidar dependency mozilla/nunjucks#1227.

[zachleat]

#1394 pertains to this, will ship with 1.0

[Krinkle]

on 22 Aug 2020:

• Eleventy 0.9.0 had 555 dependencies.
• Eleventy 0.11.0 currently has 372 dependencies. This includes well-known, disciplined, and standalone packages that solve core problems such as mustache and liquid, but also many many others. […]

Today:

• Eleventy 0.12.1 has 340 modules.
• Eleventy 1.0.0-canary.22 has 353 modules.

[boehs]

Our of curiosity, what would happen if all the supported file formats were replaced with an opt in basis? Most 11ty users probably only use md,JS,liquid,njk,html

@zachleat opinions on trying this?

[pdehaan]

Our of curiosity, what would happen if all the supported file formats were replaced with an opt in basis? Most 11ty users probably only use md,JS,liquid,njk,html

I think that's being tracked in #1103

[zachleat]

Just an update here, v2.0.0 is currently sitting at 192 modules:

https://npmgraph.js.org/?q=@11ty/eleventy@2.0.0-canary.13

[zachleat]

• 0.7.1: 474 modules
• 0.8.3: 476 modules
• 0.9.0: 402 modules
• 0.10.0: 331 modules
• 0.11.1: 331 modules
• 0.12.1: 310 modules
• 1.0.1: 309 modules
• 2.0.0-canary.13: 192 modules

[zachleat]

This is a continuous improvement ticket, and we’ll keep the work alive—but I think with #1305 complete and #1103 tracked separately we can go ahead and move this into the 2.0 milestone and close for now! Very open to more granular tasks on this specific topic filed as new issues! Thanks!