Dependency optimization

[outslept]

Replace several dependencies with more lightweight alternatives and native Node.js functionality:

• Replace p-map with custom Promise.all implementation using chunking
• Replace graceful-fs with native node:fs module (Node.js >=18 provides sufficient capabilities)
• Replace minimist with node:util.parseArgs() for CLI argument parsing
• Replace husky + lint-staged with simple-git-hooks + nano-staged (fewer sub-dependencies)

These changes reduce the deps size, lower the overall dep count, and hopefully improve maintainability while preserving identical functionality. Part of the: e18e/ecosystem-issues#164

UPD: I'm open to any change/reverts you'd like for this

[outslept]

Also here are the videos with coverage result for the fork:

fork.mp4

And for the current 11ty version

original.mp4

[zachleat]

Happy to merge this but can you move the minimist->parseArgs change to a separate PR? I don’t think parseArgs supports multi-type CLI args yet (boolean or string values) — and this is the riskiest change of the 4 I think

[zachleat]

(I fixed the conflicts I made here too)

[outslept]

Happy to merge this but can you move the minimist->parseArgs change to a separate PR? I don’t think parseArgs supports multi-type CLI args yet (boolean or string values) — and this is the riskiest change of the 4 I think

Sure thing, gimme a minute

[outslept]

Oki, I've just copied the code from https://github.com/11ty/eleventy/blob/main/cmd.cjs This test is failing locally. Does this need investigation?

UPD: Upon some investigation

The test expects DirContains("..", "../..") to return false (indicating that a directory two levels up is not contained within the parent directory), but the current implementation returns true.

This happens because the function is using a simple startsWith() check on resolved paths:

path.resolve("..") resolves to the parent directory
path.resolve("../..") resolves to a directory two levels up

When checking if the second path starts with the first using startsWith(), it returns true because both paths start with the same directory structure

I'm not deeply familiar with the codebase, but I wanted to ask if this behavior is intentional? The function seems to need a more "safe" way to determine if a folder is actually a subfolder of another, rather than just checking if the path string starts with another path string.

Would using path.relative() be a better approach here to properly determine containment relationships between directories?

[Ryuno-Ki]

path.relative() sounds like a sensible choice to me.

Maybe we can back out this piece into a separate PR to get the majority in here, though.