Skip to content
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

yarn: Resolve dev dependencies #744

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

slimreaper35
Copy link
Member

Maintainers will complete the following section

  • Commit messages are descriptive enough
  • Code coverage from testing does not decrease and new code is covered
  • Docs updated (if applicable)
  • Docs links in the code are still valid (if docs were updated)

Note: if the contribution is external (not from an organization member), the CI
pipeline will not run automatically. After verifying that the CI is safe to run:

Copy link
Collaborator

@a-ovchinnikov a-ovchinnikov left a comment

Choose a reason for hiding this comment

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

Some questions and suggestions.

cachi2/core/package_managers/yarn_classic/utils.py Outdated Show resolved Hide resolved
cachi2/core/package_managers/yarn_classic/utils.py Outdated Show resolved Hide resolved
cachi2/core/package_managers/yarn_classic/utils.py Outdated Show resolved Hide resolved
cachi2/core/package_managers/yarn_classic/utils.py Outdated Show resolved Hide resolved
@slimreaper35 slimreaper35 force-pushed the yarn-classic-dev branch 2 times, most recently from 78c6aec to 5f7cc8a Compare November 25, 2024 13:16
@slimreaper35 slimreaper35 marked this pull request as ready for review November 25, 2024 13:17
Add utility functions to identify runtime dependencies in Yarn Classic
projects:

- Implement find_runtime_deps() to identify production dependencies
  across workspaces
- Support compound key expansion in yarn.lock files
- Use BFS algorithm for efficient transitive dependency resolution

This enables proper classification of runtime dependencies based on
their usage in package.json files and transitive relationships.

Signed-off-by: Michal Šoltis <[email protected]>
Integrate dev dependency detection into the package resolution process:
- Add dev flag to YarnClassicPackageFactory
- Pass non-dev dependencies set through the resolution chain
- Update package creation to mark dependencies as dev/non-dev
- Update tests to accommodate the new dev flag

This completes the dependency classification implementation by marking
each resolved package with its development status.

Signed-off-by: Michal Šoltis <[email protected]>
@slimreaper35 slimreaper35 changed the title yarn classic dev dependencies yarn: Resolve dev dependencies Nov 28, 2024
"version": "2.0.0",
"dependencies": {"multi-dep1": "^4.0.0", "multi-dep2": "^4.0.0"},
},
"multi-dep1@^4.0.0, multi-dep2@^4.0.0": {"version": "5.0.0", "dependencies": {}},
Copy link
Collaborator

Choose a reason for hiding this comment

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

Isn't _expand_yarn_lock_keys supposed to split this key in two?

"dev-dep1@^4.0.0": {"version": "4.0.0", "dependencies": {}},
}

result = find_runtime_deps(package_json, mock_yarn_lock, [])
Copy link
Collaborator

Choose a reason for hiding this comment

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

Should there be a test for Note: If a dependency is marked as runtime dependency somewhere and as a development dependency somewhere else, it is classified as runtime? E.g. by having a simple workspace where dev-dep1 is a runtime dependency?

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