Skip to content

refactor(deps): replace find-up with empathic #5365

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 2 commits into from

Conversation

beeequeue
Copy link

@beeequeue beeequeue commented May 12, 2025

fixes #5346
fixes #5359

PR Checklist

Overview

This PR swaps find-up for the faster and smaller alternative empathic, see #5346 and #5359 for more details.

Copy link

linux-foundation-easycla bot commented May 12, 2025

CLA Signed


The committers listed above are authorized under a signed CLA.

@@ -92,7 +92,7 @@ exports.loadConfig = filepath => {
* @returns {string|null} Filepath to config, if found
*/
exports.findConfig = (cwd = utils.cwd()) => {
const filepath = findUp.sync(exports.CONFIG_FILES, {cwd});
const filepath = find.any(exports.CONFIG_FILES, {cwd});
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In one call, findUp.sync is replaced with find.any, in another, it's replaced with find.up. Is that intentional?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ref https://github.com/lukeed/empathic/blob/main/src/find.ts, they look different, can we stick with find.up for now?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is intentional, up searches for a single path while any searches for multiple:
find.up(path: string) vs. find.any(paths: string[])

@voxpelli
Copy link
Member

Posting here as well as apparently we have two issues and one PR regarding this now, so not sure where to keep the discussion:

Swapping a ≈163221k weekly downloads with 5406 dependents for a ≈32k weekly downloads with 10 dependents (and picking up steam very recently) is something that requires quite a bit of consideration and justification.

I'm not sure this is the kind of swap that mocha should be spearheading – there are other more cutting edge modules out there that can take the hit first.

There's also a lighter alternative of find-up itself that should also be considered: https://www.npmjs.com/package/find-up-simple

Remember: The smaller size gained from eg fewer transitive dependencies or a lighter module itself, that's only gained if we are the only package depending on the version of the package that we are swapping from. If it or its transitive dependencies are already installed, then a swap will actually cause a larger install, not a smaller, if the swap is to a library that the typical installation does not already have.

So it's not as simple of an equation as simply looking at package size in isolation.

@JoshuaKGoldberg
Copy link
Member

Moving to draft pending discussion in #5346.

@JoshuaKGoldberg JoshuaKGoldberg marked this pull request as draft May 19, 2025 13:44
Copy link
Member

@voxpelli voxpelli left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unfortunately I have reviewed this at depth and it would cause regressions as well as having dubious performance gains: #5346 (comment)

I see no reason to explore this further. At least not until the upstream package has become a drop-in replacement.

@voxpelli voxpelli closed this May 19, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

perf: switch to empathic for config resolution 📦 Package: Replace find-up with empathic
4 participants