NCU Error: Relative Path & Peer Dependencies Issue

Aug 7, 2025 by Rajiv Sharma 51 views

Error with Relative Dependency Path and --peer Discussion

Hey everyone! I've run into a bit of a snag while using npm-check-updates and wanted to share it here to see if anyone has encountered something similar or has any insights. I've already searched for similar issues, but haven't quite found a match.

Steps to Reproduce

I'm using Yarn 4.9.2, and I have a dependency defined using a relative path. Let's dive into the specifics.

Dependencies:

Here's the relevant snippet from my package.json file:

{
    "packageManager": "[email protected]",
    "devDependencies": {
        "@kiwiirc/eslint-plugin": "./build/plugins/eslint-rules",
    }
}

As you can see, @kiwiirc/eslint-plugin is pointing to a local directory within my project.

Steps:

To reproduce the issue, simply run the following command:

ncu --peer

This command is intended to check for updates to peer dependencies.

Current Behavior

When I run the command, I get the following error:

Error: Expected JSON from "--json npm info @kiwiirc/eslint-plugin@./build/plugins/eslint-rules --fields peerDependencies". Instead received: {"type":"error","name":35,"displayName":"YN0035","indent":"","data":"Package not found"}
{"type":"error","name":35,"displayName":"YN0035","indent":"","data":"  Response Code: 404 (Not Found)"}
{"type":"error","name":35,"displayName":"YN0035","indent":"","data":"  Request Method: GET"}
{"type":"error","name":35,"displayName":"YN0035","indent":"","data":"  Request URL: https://registry.yarnpkg.com/@kiwiirc%2feslint-plugin"}

    at pn (C:\Users\User\AppData\Roaming\npm\node_modules\npm-check-updates\build\index.js:418:24713)
    at Module.Z6 [as getPeerDependencies] (C:\Users\User\AppData\Roaming\npm\node_modules\npm-check-updates\build\index.js:464:1650)
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
    at async C:\Users\User\AppData\Roaming\npm\node_modules\npm-check-updates\build\index.js:550:652

It seems like npm-check-updates is trying to fetch information about the package from the npm registry, which obviously fails because it's a local dependency. The error message indicates that it expected JSON but received an error response because the package wasn't found in the registry. This is a crucial point because it highlights how ncu handles relative paths when checking for peer dependencies.

Breaking down the error message, we can see that the tool attempts to use npm info with the relative path as the package name. This command is designed to fetch package information from the npm registry, which is not suitable for local dependencies. The error clearly states that the package was not found, resulting in a 404 error. The subsequent lines in the error log provide further details about the failed request, including the request method (GET) and the URL used to query the registry. This information confirms that ncu is indeed trying to resolve the relative path as if it were a standard npm package.

The stack trace provided in the error message gives us a glimpse into the internal workings of npm-check-updates. It shows that the error originates from the getPeerDependencies function, which is responsible for fetching peer dependencies. The trace also indicates that the issue occurs while processing the results of the npm info command. This suggests that the tool is unable to handle the response when the package is not found in the registry. By examining the stack trace, we can pinpoint the exact location in the code where the error occurs, which can be helpful for debugging and identifying potential solutions. The process.processTicksAndRejections line in the trace indicates that the error occurs within an asynchronous operation, which is common when dealing with network requests and external processes. This highlights the importance of handling asynchronous errors properly to prevent unexpected behavior.

Expected Behavior

Ideally, npm-check-updates should either:

Look for a package.json file within the relative path and extract the relevant information from there.
Ignore the dependency altogether, as it's not a standard npm package.

In my opinion, either of these behaviors would be an improvement over the current one. The ability to correctly handle relative paths is crucial for projects that use local dependencies or monorepo setups. Ignoring the dependency would at least prevent the tool from crashing and provide a more accurate list of available updates for other packages. However, ideally, ncu should be able to inspect the package.json file within the relative path and extract the necessary information, such as the package version and peer dependencies. This would allow users to manage their local dependencies more effectively and ensure that they are compatible with other packages in the project.

The suggestion to look for a package.json file within the relative path aligns with the way other package management tools handle local dependencies. For example, Yarn and npm both allow you to specify local dependencies in your package.json file, and they will automatically link the local package into your project. By adopting a similar approach, ncu could provide a more consistent and intuitive experience for users. Alternatively, ignoring the dependency would be a simpler solution that would still prevent the tool from crashing. This approach would be suitable for projects that don't need to check for updates to their local dependencies. However, it would be less comprehensive than inspecting the package.json file, as it would not provide information about the package version or peer dependencies.

In summary, the expected behavior is that npm-check-updates should either correctly handle relative dependency paths by inspecting the package.json file within the path or ignore them altogether to avoid errors. This would significantly improve the usability of the tool for projects that use local dependencies.

Additional Context and Potential Solutions

This issue seems to stem from how npm-check-updates attempts to resolve dependencies and fetch their information. When it encounters a relative path, it incorrectly tries to treat it as a package on the npm registry. This is a common problem when tools designed for registry-based packages encounter local or file-based dependencies. The core challenge here is that npm-check-updates doesn't have a mechanism to distinguish between registry packages and local packages.

One potential solution could involve modifying npm-check-updates to detect relative paths and handle them differently. This could be achieved by checking if the dependency path starts with ./ or ../. If it does, the tool could then attempt to read the package.json file in that directory and extract the necessary information. This approach would require adding new logic to the tool to parse package.json files and handle the specific case of local dependencies. Alternatively, the tool could simply ignore dependencies specified with relative paths. This would be a simpler solution but would mean that users would not be able to check for updates to their local dependencies using npm-check-updates. This might be acceptable for some projects, but it would limit the tool's usefulness in monorepo setups or projects with many local dependencies.

Another potential solution could involve leveraging Yarn's or npm's internal APIs to resolve dependencies. Both Yarn and npm have mechanisms for resolving dependencies, including local and file-based dependencies. By using these APIs, npm-check-updates could potentially avoid the need to implement its own dependency resolution logic. However, this approach might make the tool more tightly coupled to Yarn or npm, which could be a disadvantage if the APIs change in the future. It would also require a deeper understanding of Yarn's and npm's internals, which could increase the complexity of the project.

A further consideration is the user experience. If npm-check-updates is unable to handle relative paths, it should provide a clear and informative error message to the user. The current error message, which indicates that the package was not found in the registry, is somewhat misleading. A better error message would explain that the tool is unable to handle dependencies specified with relative paths and suggest alternative approaches, such as manually checking for updates or using a different tool. Providing a clear error message would help users understand the issue and avoid wasting time trying to debug it.

In summary, there are several potential solutions to this issue, each with its own trade-offs. The best approach will depend on the specific goals of the project and the resources available for development. A combination of techniques might also be used, such as ignoring dependencies with relative paths by default but providing an option to enable more advanced handling for users who need it.

I'm curious to hear your thoughts and if anyone has any workarounds or suggestions. Let's discuss!