Proposal: drop rimraf and lint-staged as part of e18e cleanup?

[Adebesin-Cell]

Not a hard proposal, more taking the temperature of the community on this one 🙂

As part of the broader e18e effort (reducing install size / dropping packages that now have native or lighter equivalents), I noticed Panda still pulls in a couple of dev dependencies that have well-trodden replacements. Wanted to lay out where they're used and the tradeoffs.

rimraf

Used in a few scripts:

• clean → pnpm -r --parallel exec rimraf dist .turbo *.log
• reset → pnpm -r --parallel exec rimraf node_modules && rimraf node_modules
• sandbox/next-js-{app,pages} dev → rimraf .next && next dev

e18e suggests native fs.rm ({ recursive: true, force: true }), available since Node 14.14.

The single-path cases (.next, node_modules) are easy to swap. The one that needs thought is clean, it passes multiple paths and a glob (*.log), and fs.rm doesn't handle globs or multiple args. So that one would either need a small helper script or to keep leaning on shell expansion. Curious whether folks think the win is worth that bit of friction, or whether it's cleaner to just leave clean as-is.

lint-staged

.husky/pre-commit runs lint-staged with a single config entry. e18e suggests nano-staged, same package.json config shape, much smaller.

The caveat is nano-staged drops the more advanced bits (stash/partial-staging, per-dir monorepo configs). Panda's current config looks simple enough that this shouldn't matter, but flagging it in case there's history I'm missing.

Question

Worth doing? Mostly want to check there's no reason these were chosen deliberately before anyone spends time on it.

[segunadebayo]

Sounds good to me. Feel free to open a PR for this

[Adebesin-Cell]

Opened #3555 for this.

Covers both:

• rimraf → native fs.rm / fs.globSync in clean, reset, and the two next-js sandbox dev scripts
• lint-staged → nano-staged (same config shape, zero deps)

On the clean question from above: since it passes multiple paths plus the *.log glob, I used fs.globSync + fs.rmSync inline rather than adding a helper script, so it stays dependency-free and behaves the same.

Also worth noting, nano-staged v1 still does the stash / partial-staging flow, so the one tradeoff I flagged for it isn't actually a downside anymore.

(Transitive rimraf via gatsby and friends stays in the lockfile, that's out of scope here.)