It’s technically valid, but it’s a lateral move rather than an improvement to an actual problem. Chasing a couple milliseconds of perf here on a build script run very occasionally is not worth the investment of either of our time.

I don’t merge or review refactors unless there’s a compelling reason like a bug, a measured performance gain, enabling new functionality, or maintainability on code we expect to revisit eventually.

Every change has a review cost, and I’d rather spend that time on changes with meaningful impact.

If you’re interested in contributing to mime-db or the expressjs org, I’d encourage you to look for actual issues to solve rather than refactoring working code.

@jonchurch Thanks for your time and for maintaining these projects.

It's technically valid, but it's a lateral move rather than an improvement to an actual problem. Chasing a couple milliseconds of perf here on a build script run very occasionally is not worth the investment of either of our time.

I understand and appreciate your perspective. While I believe a micro-optimization is always a good optimization, I respect your decision on where to prioritize review time.

I don't merge or review refactors unless there's a compelling reason like a bug, a measured performance gain, enabling new functionality, or maintainability on code we expect to revisit eventually.

I wanted to mention that I have been working on actual bug fixes in the expressjs ecosystem. I have PR #652 open in expressjs/body-parser that addresses a fix (not a refactor). It's been waiting for review for a while now, and I'd appreciate it if you could take a look when you have a chance.