Enhance bazel-diff to Determine Affected Targets Using pnpm-lock.yaml Granularly

[Arsen-Zhakypbek-Uulu]

Description:

Hello maintainers,

I would like to propose an enhancement to the Tinder/bazel-diff project that allows for a more granular detection of affected targets based on changes in the pnpm-lock.yaml file.

Context:

We are using Bazel in conjunction with the pnpm package manager to manage multiple JavaScript/TypeScript applications. Each application has its own package.json, and dependencies are managed collectively via the pnpm-lock.yaml file.

Problem Statement:

Currently, when the pnpm-lock.yaml file changes, bazel-diff indicates that all JS/TS applications need to be rebuilt. However, this is often unnecessary as not all applications are affected by changes in locked dependencies. Different applications might have different versions of the same package or might not be affected by a particular version change at all.

Proposed Solution:

Add a feature to bazel-diff that:

Analyzes changes within the pnpm-lock.yaml file.
Maps these changes to specific applications' package.json dependencies.
Identifies only those applications that are truly affected by these changes, avoiding unnecessary rebuilds.
Benefits:

Increased efficiency in the build process by avoiding unnecessary rebuilds.
Better resource utilization in CI/CD environments.
Faster feedback for developers due to reduced build times.
Reference:

Aspect has been gaining popularity for building JS/TS applications with Bazel and supports pnpm. Considering its approach might provide some insights or strategies to implement this feature.

Thank you for considering this feature request. It would greatly enhance our development workflow and I believe it could be beneficial for others in the community as well.

Looking forward to your feedback or any suggestions on this proposal.

Feel free to customize the request with any additional information or context specific to your needs.

[matthewjh]

I don't think bazel-diff is going to implement this or should do as it is coupled to bazel's graph, not library- or framework-specific dynamics.

A better approach would be to figure out the way for the ruleset to more effectively encode this information into bazel's graph. To that end, I think you should post this in the rules_js repo.