Skip to content

Conversation

@lukeed
Copy link

@lukeed lukeed commented May 31, 2025

Disclaimer: I am the author of empathic

Replaces find-up with a much lighter-weight, faster alternative. Doing so cleans up the detect logic (since there's no difference in handling .git files or directories) and significantly (for this module) cleans up the dependency graph.

  • tests pass
  • engines.node match
  • native ESM and native CJS are both offered

This is part of the e18e initiative, which I believe @JounQin is active within.


Important

Replace find-up with empathic in git.ts and hg.ts, simplifying detection logic and reducing dependencies.

  • Dependencies:
    • Replace find-up with empathic in package.json.
  • Code Changes:
    • Simplify detect function in git.ts and hg.ts using empathic.
    • Remove fs import from git.ts as it's no longer needed.
  • Misc:
    • All tests pass, ensuring compatibility with the new dependency.
    • engines.node remains compatible with the new package.

This description was created by Ellipsis for 73c364d. You can customize this summary. It will automatically update as commits are pushed.

Summary by CodeRabbit

  • Chores
    • Updated dependencies by replacing "find-up" with "empathic".
    • Simplified internal logic for detecting project directories, improving efficiency and maintainability. No changes to user-facing features or functionality.

@changeset-bot
Copy link

changeset-bot bot commented May 31, 2025

⚠️ No Changeset found

Latest commit: 9eeb923

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

@coderabbitai
Copy link

coderabbitai bot commented May 31, 2025

"""

Walkthrough

The changes update the codebase to replace the use of the "find-up" package with the "empathic" package for finding VCS directories. The relevant import statements and directory detection logic in the Git and Mercurial modules are updated accordingly, and the dependency is changed in package.json.

Changes

File(s) Change Summary
package.json Replaced "find-up" dependency with "empathic".
src/scms/git.ts Replaced "find-up" and "fs" imports with "empathic/find"; simplified .git detection logic.
src/scms/hg.ts Replaced "find-up" import with "empathic/find"; simplified .hg detection logic with directory check.

Sequence Diagram(s)

sequenceDiagram
    participant Caller
    participant GitModule
    participant EmpathicFind

    Caller->>GitModule: detect(directory)
    GitModule->>EmpathicFind: find.up('.git', { cwd: directory })
    EmpathicFind-->>GitModule: path or null
    GitModule-->>Caller: dirname(path) or null
Loading
sequenceDiagram
    participant Caller
    participant HgModule
    participant EmpathicFind

    Caller->>HgModule: detect(directory)
    HgModule->>EmpathicFind: find.up('.hg', { cwd: directory })
    EmpathicFind-->>HgModule: path or null
    HgModule->>HgModule: check if path is directory
    HgModule-->>Caller: dirname(path) or null
Loading

Poem

In the warren, code hops anew,
"find-up" has left, "empathic" grew.
Git and Hg now sniff their trails,
With simpler steps and lighter tails.
A burrow cleaned, dependencies few—
Hooray for change, and carrots too! 🥕
"""


📜 Recent review details

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 8491af2 and 9eeb923.

📒 Files selected for processing (1)
  • src/scms/hg.ts (1 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
  • src/scms/hg.ts
✨ Finishing Touches
  • 📝 Generate Docstrings

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share
🪧 Tips

Chat

There are 3 ways to chat with CodeRabbit:

  • Review comments: Directly reply to a review comment made by CodeRabbit. Example:
    • I pushed a fix in commit <commit_id>, please review it.
    • Explain this complex logic.
    • Open a follow-up GitHub issue for this discussion.
  • Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
    • @coderabbitai explain this code block.
    • @coderabbitai modularize this function.
  • PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
    • @coderabbitai gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
    • @coderabbitai read src/utils.ts and explain its main purpose.
    • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.
    • @coderabbitai help me debug CodeRabbit configuration file.

Support

Need help? Create a ticket on our support page for assistance with any issues or questions.

Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments.

CodeRabbit Commands (Invoked using PR comments)

  • @coderabbitai pause to pause the reviews on a PR.
  • @coderabbitai resume to resume the paused reviews.
  • @coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
  • @coderabbitai full review to do a full review from scratch and review all the files again.
  • @coderabbitai summary to regenerate the summary of the PR.
  • @coderabbitai generate docstrings to generate docstrings for this PR.
  • @coderabbitai generate sequence diagram to generate a sequence diagram of the changes in this PR.
  • @coderabbitai resolve resolve all the CodeRabbit review comments.
  • @coderabbitai configuration to show the current CodeRabbit configuration for the repository.
  • @coderabbitai help to get help.

Other keywords and placeholders

  • Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
  • Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
  • Add @coderabbitai anywhere in the PR title to generate the title automatically.

CodeRabbit Configuration File (.coderabbit.yaml)

  • You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
  • Please see the configuration documentation for more information.
  • If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json

Documentation and Community

  • Visit our Documentation for detailed information on how to use CodeRabbit.
  • Join our Discord Community to get help, request features, and share feedback.
  • Follow us on X/Twitter for updates and announcements.

@codesandbox-ci
Copy link

codesandbox-ci bot commented May 31, 2025

This pull request is automatically built and testable in CodeSandbox.

To see build info of the built libraries, click here or the icon next to each commit SHA.

Copy link

@ellipsis-dev ellipsis-dev bot left a comment

Choose a reason for hiding this comment

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

Important

Looks good to me! 👍

Reviewed everything up to 73c364d in 1 minute and 23 seconds. Click for details.
  • Reviewed 95 lines of code in 3 files
  • Skipped 1 files when reviewing.
  • Skipped posting 3 draft comments. View those below.
  • Modify your settings and rules to customize what types of comments Ellipsis leaves. And don't forget to react with 👍 or 👎 to teach Ellipsis.
1. package.json:60
  • Draft comment:
    Dependency change: Ensure that empathic’s behavior is fully compatible with find-up, particularly in how it resolves both file and directory entries for .git/.hg.
  • Reason this comment was not posted:
    Comment did not seem useful. Confidence is useful = 0% <= threshold 50% This comment is asking the PR author to ensure compatibility between dependencies, which violates the rule against asking for confirmation or testing of behavior. It does not provide a specific suggestion or point out a specific issue.
2. src/scms/git.ts:9
  • Draft comment:
    The simplified detect logic now uses find.up and returns path.dirname(found). Verify that this uniformly handles cases where .git might be a file or directory, as the previous logic differentiated between these cases.
  • Reason this comment was not posted:
    Comment did not seem useful. Confidence is useful = 0% <= threshold 50% The comment is asking the author to verify the behavior of the new logic, which is against the rules. It doesn't provide a specific suggestion or point out a clear issue with the code. Therefore, it should be removed.
3. src/scms/hg.ts:9
  • Draft comment:
    The detect function for hg now returns path.dirname(found) when found. Note that if no .hg directory is found it implicitly returns undefined, whereas the git.ts detect returns null. Consider unifying the return type for consistency.
  • Reason this comment was not posted:
    Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50% While the comment identifies a real inconsistency, I can't verify if git.ts actually returns null without seeing that file. The comment requires cross-file context which violates our rules. Additionally, this type inconsistency existed before the change - it wasn't introduced by this PR. The inconsistency could be a real issue that affects type safety in the codebase. Maybe we should keep comments about type safety even if they're about pre-existing issues? No - our rules are clear that we should only comment on changes introduced by the PR, and that we should ignore cross-file issues. We can't verify the git.ts behavior without more context. Delete this comment because it discusses a pre-existing cross-file issue rather than a problem introduced by the changes in this PR.

Workflow ID: wflow_79BKNOOd0XxISLn6

You can customize Ellipsis by changing your verbosity settings, reacting with 👍 or 👎, replying to comments, or adding code review rules.

Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

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

Actionable comments posted: 0

🧹 Nitpick comments (1)
src/scms/git.ts (1)

9-11: Fix inconsistency with hg.ts return value.

The function correctly implements the simplified detection logic. However, there's an inconsistency: this function explicitly returns null when not found, while the equivalent function in src/scms/hg.ts (lines 10-11) implicitly returns undefined.

For consistency, consider updating src/scms/hg.ts to also explicitly return null:

export const detect = (directory: string) => {
  const found = find.up('.hg', { cwd: directory })
-  if (found) return path.dirname(found)
+  return found ? path.dirname(found) : null
}

Alternatively, update this function to match hg.ts:

export const detect = (directory: string) => {
  const found = find.up('.git', { cwd: directory })
-  return found ? path.dirname(found) : null
+  if (found) return path.dirname(found)
}
📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between f8b9eb8 and 73c364d.

⛔ Files ignored due to path filters (1)
  • yarn.lock is excluded by !**/yarn.lock, !**/*.lock
📒 Files selected for processing (3)
  • package.json (1 hunks)
  • src/scms/git.ts (1 hunks)
  • src/scms/hg.ts (1 hunks)
🧰 Additional context used
🧬 Code Graph Analysis (1)
src/scms/git.ts (2)
src/scms/hg.ts (2)
  • name (6-6)
  • detect (8-11)
src/scms/index.ts (1)
  • directory (6-16)
🔇 Additional comments (4)
package.json (1)

60-60:

✅ Verification successful

Verify the empathic package version and security.

The dependency change from find-up to empathic aligns with the code changes. Please ensure this specific version is secure and compatible.


🌐 Web query:

What is the latest version of the empathic npm package and are there any known security vulnerabilities?

💡 Result:

Based on the search results, the latest version of the empathic npm package is 1.1.0, released approximately 2 weeks ago as of May 31, 2025[3]. The package is described as a set of small Node.js utilities designed to understand pathing needs. It offers multiple submodules like empathic/find and empathic/package that are fast, modern, small in size, and safe with zero dependencies[3].

Regarding security vulnerabilities, there is no specific information in the search results about any known security vulnerabilities for the empathic package itself. The package is described as "safe" and having "zero-dependency," which typically reduces the attack surface for potential vulnerabilities[3].

The empathic package includes several modules:

  • empathic/access: For checking file access/permissions
  • empathic/find: For finding files and directories by walking up parent directories
  • empathic/package: Convenience helpers for dealing with package.json files
  • empathic/resolve: For resolving absolute paths
  • empathic/walk: For collecting parent directories of a target[3]

While there is information about vulnerabilities in npm packages in general and the npm package manager itself, none of the search results specifically mention any security issues with the empathic package[6][9][10].

Citations:


Confirmed: empathic@1.1.0 is up-to-date and secure

The dependency upgrade from find-up to "empathic": "^1.1.0" matches the latest release (v1.1.0, May 31 2025) and leverages its zero-dependency modules (e.g. empathic/find). No known security vulnerabilities have been reported. You can safely proceed with this change.

src/scms/hg.ts (2)

3-3: LGTM: Import updated correctly.

The import change from find-up to empathic/find aligns with the dependency update and PR objectives.


9-11: LGTM: Detect function simplified as intended.

The function correctly implements the simplified detection logic using find.up(). The removal of the type: 'directory' constraint aligns with the PR objective to remove the distinction between handling .hg files or directories.

src/scms/git.ts (1)

3-3: LGTM: Import updated correctly.

The import change from find-up to empathic/find aligns with the dependency update and PR objectives.

if (hgDirectory) {
return path.dirname(hgDirectory)
}
const found = find.up('.hg', { cwd: directory })
Copy link
Member

Choose a reason for hiding this comment

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

What if there is a .hg file?

Copy link
Author

Choose a reason for hiding this comment

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

It's always a directory. If you have a .hg file your mercurial project would be broken

Copy link
Member

@JounQin JounQin Jun 1, 2025

Choose a reason for hiding this comment

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

Nope, that just means there is a .hg file and it's not a mercurial project.

Copy link
Author

Choose a reason for hiding this comment

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

We can stat the result to check if it's a directory, tho the odds of this happening is very low.

Copy link
Member

Choose a reason for hiding this comment

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

That's how previous codes work. Dependency migration should not change any current behavior.

@JounQin
Copy link
Member

JounQin commented Jun 1, 2025

I just tried my own @pkgr/core which is already used in synckit at https://github.com/JounQin/empathic/tree/chore/pkgr-find-up, and the benchmark shows findUp from @pkgr/core is much faster:

 empathic on  chore/pkgr-find-up [+] ❯ deno bench --allow-read --allow-env
Check file:///Users/JounQin/Workspaces/GitHub/empathic/src/find.bench.ts
Check file:///Users/JounQin/Workspaces/GitHub/empathic/src/locate.bench.ts
Check file:///Users/JounQin/Workspaces/GitHub/empathic/src/package.bench.ts
Check file:///Users/JounQin/Workspaces/GitHub/empathic/src/resolve.bench.ts
Check file:///Users/JounQin/Workspaces/GitHub/empathic/src/walk.bench.ts
    CPU | Apple M4
Runtime | Deno 2.3.3 (aarch64-apple-darwin)

file:///Users/JounQin/Workspaces/GitHub/empathic/src/find.bench.ts

benchmark                 time/iter (avg)        iter/s      (min … max)           p75      p99     p995
------------------------- ----------------------------- --------------------- --------------------------

group level-6
pkgr-find-up                       3.5 µs       284,100 (  3.3 µs …   4.4 µs)   3.6 µs   4.4 µs   4.4 µs
find-up                          186.7 µs         5,357 (102.8 µs …   3.7 ms) 212.7 µs 600.3 µs 762.7 µs
find-up-simple                   138.9 µs         7,199 ( 80.3 µs …   1.5 ms) 165.9 µs 368.4 µs 423.6 µs
find-up-simple (sync)             63.7 µs        15,700 ( 45.3 µs …   1.8 ms)  64.6 µs 188.8 µs 213.7 µs
escalade                         225.8 µs         4,428 ( 94.1 µs …   1.5 ms) 287.4 µs 668.0 µs 805.5 µs
find.up (alt)                    198.0 µs         5,051 ( 84.2 µs … 962.6 µs) 254.6 µs 549.0 µs 634.2 µs
empathic/find.up (sync)            9.2 µs       108,100 (  5.2 µs … 212.4 µs)   9.9 µs  51.6 µs  61.8 µs

summary
  pkgr-find-up
     2.63x faster than empathic/find.up (sync)
    18.09x faster than find-up-simple (sync)
    39.46x faster than find-up-simple
    53.03x faster than find-up
    56.24x faster than find.up (alt)
    64.15x faster than escalade

group level-10
pkgr-find-up                       3.5 µs       282,500 (  3.3 µs …   4.3 µs)   3.6 µs   4.3 µs   4.3 µs
find-up                          427.1 µs         2,341 (246.0 µs …   3.1 ms) 485.3 µs 975.4 µs   1.2 ms
find-up-simple                   416.5 µs         2,401 (203.6 µs …   3.0 ms) 482.3 µs   1.1 ms   1.3 ms
find-up-simple (sync)            192.4 µs         5,199 (136.7 µs …   1.0 ms) 190.7 µs 588.7 µs 663.3 µs
escalade                         279.3 µs         3,580 (204.7 µs …   1.6 ms) 274.2 µs 913.0 µs   1.0 ms
find.up (alt)                    232.2 µs         4,308 (192.8 µs …   1.0 ms) 234.0 µs 419.2 µs 497.0 µs
empathic/find.up (sync)           19.0 µs        52,530 ( 11.2 µs … 334.5 µs)  21.2 µs  96.3 µs 110.2 µs

summary
  pkgr-find-up
     5.38x faster than empathic/find.up (sync)
    54.35x faster than find-up-simple (sync)
    65.59x faster than find.up (alt)
    78.92x faster than escalade
   117.70x faster than find-up-simple
   120.70x faster than find-up

group missing
pkgr-find-up                       3.8 µs       265,600 (  3.3 µs …   4.3 µs)   3.9 µs   4.3 µs   4.3 µs
find-up                          560.5 µs         1,784 (350.3 µs …   3.0 ms) 619.2 µs 894.3 µs   1.7 ms
find-up-simple                   463.5 µs         2,158 (275.9 µs …   1.9 ms) 519.5 µs 832.0 µs   1.0 ms
find-up-simple (sync)            232.0 µs         4,311 (187.2 µs … 609.4 µs) 239.0 µs 423.8 µs 464.7 µs
escalade                         591.0 µs         1,692 (351.3 µs …   1.4 ms) 652.8 µs   1.1 ms   1.2 ms
find.up (alt)                    532.9 µs         1,876 (338.4 µs …   1.8 ms) 589.0 µs 922.6 µs 981.4 µs
empathic/find.up (sync)           24.4 µs        40,920 ( 14.6 µs … 323.2 µs)  29.3 µs 105.6 µs 121.2 µs

summary
  pkgr-find-up
     6.49x faster than empathic/find.up (sync)
    61.61x faster than find-up-simple (sync)
   123.10x faster than find-up-simple
   141.60x faster than find.up (alt)
   148.90x faster than find-up
   157.00x faster than escalade


file:///Users/JounQin/Workspaces/GitHub/empathic/src/locate.bench.ts

benchmark                  time/iter (avg)        iter/s      (min … max)           p75      p99     p995
-------------------------- ----------------------------- --------------------- --------------------------

group locate-6
pkgr-find-up                        3.6 µs       279,400 (  3.3 µs …   4.1 µs)   3.6 µs   4.1 µs   4.1 µs
locate-path                        81.7 µs        12,240 ( 53.4 µs …   3.3 ms)  81.8 µs 226.9 µs 257.7 µs
locate-path (sync)                 88.7 µs        11,270 ( 62.7 µs … 361.7 µs)  93.0 µs 224.1 µs 245.5 µs
locate-path (order)                83.1 µs        12,030 ( 53.5 µs …   1.8 ms)  83.2 µs 231.2 µs 278.2 µs
find-up                             1.5 ms         683.3 (  1.1 ms …   6.8 ms)   1.5 ms   3.2 ms   3.7 ms
find-up (sync)                      1.7 ms         598.3 (  1.1 ms …   2.5 ms)   1.8 ms   2.3 ms   2.5 ms
escalade                          154.7 µs         6,464 ( 93.3 µs …   1.6 ms) 179.5 µs 361.0 µs 406.2 µs
empathic/find.any (sync)           58.6 µs        17,060 ( 34.8 µs … 333.0 µs)  74.2 µs 194.3 µs 221.2 µs

summary
  pkgr-find-up
    16.37x faster than empathic/find.any (sync)
    22.82x faster than locate-path
    23.22x faster than locate-path (order)
    24.79x faster than locate-path (sync)
    43.22x faster than escalade
   408.90x faster than find-up
   466.90x faster than find-up (sync)

group locate-10
pkgr-find-up                        3.4 µs       296,900 (  3.3 µs …   3.6 µs)   3.4 µs   3.6 µs   3.6 µs
locate-path                        82.1 µs        12,170 ( 54.9 µs …   2.2 ms)  83.2 µs 221.5 µs 258.8 µs
locate-path (sync)                 95.9 µs        10,430 ( 75.0 µs … 536.3 µs) 100.1 µs 209.8 µs 243.4 µs
locate-path (order)                79.4 µs        12,590 ( 54.9 µs …   1.8 ms)  81.0 µs 199.1 µs 227.5 µs
find-up                             1.3 ms         743.5 (  1.1 ms …   2.0 ms)   1.4 ms   1.9 ms   2.0 ms
find-up (sync)                      1.9 ms         536.0 (  1.5 ms …   4.8 ms)   1.9 ms   3.3 ms   3.9 ms
escalade                          353.5 µs         2,829 (209.7 µs …   2.1 ms) 396.0 µs 657.7 µs 780.7 µs
empathic/find.any (sync)          140.1 µs         7,136 ( 78.4 µs … 571.7 µs) 170.7 µs 449.6 µs 486.7 µs

summary
  pkgr-find-up
    23.59x faster than locate-path (order)
    24.39x faster than locate-path
    28.48x faster than locate-path (sync)
    41.61x faster than empathic/find.any (sync)
   105.00x faster than escalade
   399.30x faster than find-up
   553.90x faster than find-up (sync)

group missing-15
pkgr-find-up                        3.3 µs       299,400 (  3.2 µs …   4.0 µs)   3.4 µs   4.0 µs   4.0 µs
locate-path                        80.2 µs        12,460 ( 54.2 µs … 630.6 µs)  81.4 µs 205.8 µs 232.7 µs
locate-path (sync)                100.7 µs         9,935 ( 82.5 µs … 495.7 µs) 105.5 µs 211.2 µs 257.1 µs
locate-path (order)                78.7 µs        12,700 ( 54.0 µs …   1.8 ms)  80.6 µs 194.2 µs 212.8 µs
find-up                             1.3 ms         747.4 (  1.1 ms …   2.0 ms)   1.4 ms   1.9 ms   2.0 ms
find-up (sync)                      1.9 ms         531.8 (  1.6 ms …   2.5 ms)   1.9 ms   2.3 ms   2.3 ms
escalade                          582.1 µs         1,718 (362.7 µs …   1.1 ms) 652.4 µs 898.4 µs 971.3 µs
empathic/find.any (sync)          166.1 µs         6,022 ( 99.9 µs … 655.2 µs) 210.5 µs 440.2 µs 474.0 µs

summary
  pkgr-find-up
    23.57x faster than locate-path (order)
    24.03x faster than locate-path
    30.14x faster than locate-path (sync)
    49.72x faster than empathic/find.any (sync)
   174.30x faster than escalade
   400.60x faster than find-up
   563.00x faster than find-up (sync)


file:///Users/JounQin/Workspaces/GitHub/empathic/src/package.bench.ts

benchmark                    time/iter (avg)        iter/s      (min … max)           p75      p99     p995
---------------------------- ----------------------------- --------------------- --------------------------

group pkg-up
pkgr-find-up                          3.3 µs       304,000 (  3.0 µs …   3.8 µs)   3.4 µs   3.8 µs   3.8 µs
package-up                          254.4 µs         3,931 (148.8 µs … 623.9 µs) 300.7 µs 463.3 µs 503.2 µs
package-up (sync)                   114.3 µs         8,748 ( 86.2 µs … 360.6 µs) 119.8 µs 257.7 µs 299.2 µs
pkg-up                              325.2 µs         3,075 (183.9 µs …   2.7 ms) 363.3 µs 723.2 µs 941.2 µs
pkg-up (sync)                       136.4 µs         7,330 ( 93.3 µs … 599.1 µs) 139.5 µs 323.2 µs 355.7 µs
empathic/package.up (sync)           15.4 µs        64,940 (  9.1 µs … 159.7 µs)  18.5 µs  68.9 µs  77.9 µs

summary
  pkgr-find-up
     4.68x faster than empathic/package.up (sync)
    34.76x faster than package-up (sync)
    41.48x faster than pkg-up (sync)
    77.35x faster than package-up
    98.89x faster than pkg-up

group pkg-dir
pkg-dir                             248.0 µs         4,032 (150.5 µs … 660.5 µs) 293.8 µs 476.2 µs 511.0 µs
pkgr-find-up                          3.2 µs       315,100 (  3.0 µs …   3.6 µs)   3.2 µs   3.6 µs   3.6 µs
pkg-dir (sync)                      111.7 µs         8,956 ( 85.5 µs … 379.2 µs) 117.9 µs 236.9 µs 267.9 µs
empathic/package.up (sync)           14.8 µs        67,770 (  9.0 µs … 179.0 µs)  17.8 µs  66.2 µs  77.0 µs

summary
  pkgr-find-up
     4.65x faster than empathic/package.up (sync)
    35.18x faster than pkg-dir (sync)
    78.15x faster than pkg-dir

group find-cache-dir
find-cache-dir                      173.6 µs         5,759 (134.5 µs … 577.8 µs) 181.0 µs 319.5 µs 364.9 µs
empathic/package.cache               32.9 µs        30,410 ( 21.6 µs … 226.6 µs)  37.0 µs 114.2 µs 126.8 µs

summary
  empathic/package.cache
     5.28x faster than find-cache-dir


file:///Users/JounQin/Workspaces/GitHub/empathic/src/resolve.bench.ts

benchmark               time/iter (avg)        iter/s      (min … max)           p75      p99     p995
----------------------- ----------------------------- --------------------- --------------------------

group resolve-from
resolve-from                    59.1 µs        16,930 ( 24.6 µs … 437.5 µs)  62.5 µs 170.6 µs 186.6 µs
empathic/resolve.from           39.4 µs        25,400 ( 19.0 µs … 410.0 µs)  42.4 µs 118.4 µs 131.0 µs

summary
  empathic/resolve.from
     1.50x faster than resolve-from

group resolve-cwd
resolve-cwd                     25.9 µs        38,650 ( 24.3 µs … 155.4 µs)  25.7 µs  32.0 µs  40.1 µs
empathic/resolve.cwd            23.3 µs        42,990 ( 21.9 µs … 379.2 µs)  23.0 µs  28.4 µs  33.7 µs

summary
  empathic/resolve.cwd
     1.11x faster than resolve-cwd


file:///Users/JounQin/Workspaces/GitHub/empathic/src/walk.bench.ts

benchmark                       time/iter (avg)        iter/s      (min … max)           p75      p99     p995
------------------------------- ----------------------------- --------------------- --------------------------
empathic/walk.up (no options)            9.5 µs       104,900 (  5.2 µs … 332.0 µs)   9.6 µs  29.7 µs  34.6 µs
empathic/walk.up                         9.0 µs       111,300 (  5.2 µs … 136.0 µs)   9.2 µs  27.3 µs  31.1 µs
split1                                  11.7 µs        85,190 (  7.3 µs … 234.0 µs)  11.5 µs  34.6 µs  39.2 µs
split2                                   9.7 µs       103,000 (  5.6 µs … 173.3 µs)   9.7 µs  30.3 µs  34.7 µs
split3                                   9.0 µs       111,000 (  5.2 µs … 123.7 µs)   9.2 µs  27.6 µs  31.3 µs
split4                                   9.2 µs       108,700 (  5.3 µs … 137.9 µs)   9.4 µs  27.8 µs  31.4 µs

So it seems I'm not going to use empathic, I'm sorry.

By the way, IMO resolve is not suitable to be located in empathic, since you alreay have https://github.com/lukeed/resolve.exports or userland require.resolve. Of course, it's just my opinion. On the otherhand, https://github.com/unrs/unrs-resolver may replace resolve and resolve.exports in jestjs/jest#15619.

@lukeed
Copy link
Author

lukeed commented Jun 1, 2025

empathic/resolve has nothing to do with package exports. It's meant to replace resolve-cwd|resolve-from using native APIs.

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.

2 participants