dependabot / dependabot/dependabot-core
composer - prevent updating unnecessary dependencies - ability to set `setWhitelistTransitiveDependencies(false)`
- Dominant language
- Ruby
- Stars
- 5.8k
- Forks
- 1.5k
- Avg merge
- 2d 18h
- Merged PRs (30d)
- 149
Description
Hello
Firstly, thanks for the tool.
# Summary
The tool seems to run commands like
```
composer update foo/bar --update-with-dependencies
```
I would like it if we could have it attempt to run like so as a preference
```
composer update foo/bar
```
I think this is the line of code responsible
https://github.com/dependabot/dependabot-core/blob/58d4c73917dcb52757baa36cde45696729e35334/helpers/php/src/Updater.php#L74
Some dependency chains can cause a lot of packages to update. A recent package I tagged had dependabot also change 13 additional package updates, 1 package addition, 1 package removal. These all passed through my CI pipeline okay, but it still adds unnecessary doubt in the update and means i have to update a lot more packages than what I'm currently interested in.
To be clear we do update the packages in bulk reasonably frequently, but when I update an internal package with a bugfix and want that to be easily rolled out over several clients it would be nice to have dependabot do that lifting for me, raise the PR, and get it running through CI without bundling in an additional handful of package changes which may vary per client depending on dependency chains.
This limits the value of the dependabot tooling in my case. I find myself manually doing the task so that I only update the single package I am interested in.
# Tech Details
`dependabot.yml` is a like
```yml
version: 2
registries:
composer:
type: composer-repository
url: https://repo.packagist.com/redacted/
username: token
password: redacted
updates:
- package-ecosystem: "composer"
directory: "/"
registries:
- composer
schedule:
interval: "daily"
time: "05:00"
timezone: "Europe/London"
open-pull-requests-limit: 10
```
So a recent pull request I have is like
```
Bump magento/magento-coding-standard from 8 to 15
```
The changes to the lockfile are like so

This seems to match the results of the following command
```bash
$ composer require --dev magento/magento-coding-standard:"15" --update-with-dependencies
./composer.json has been updated
Running composer update magento/magento-coding-standard --with-dependencies
Loading composer repositories with package information
Updating dependencies
Lock file operations: 0 installs, 2 updates, 0 removals
- Upgrading squizlabs/php_codesniffer (3.6.0 => 3.6.1)
- Upgrading webonyx/graphql-php (v14.9.0 => v14.11.1)
Writing lock file
Installing dependencies from lock file (including require-dev)
Package operations: 0 installs, 2 updates, 0 removals
- Downloading webonyx/graphql-php (v14.11.1)
- Downloading squizlabs/php_codesniffer (3.6.1)
- Upgrading webonyx/graphql-php (v14.9.0 => v14.11.1): Extracting archive
- Upgrading squizlabs/php_codesniffer (3.6.0 => 3.6.1): Extracting archive
````
What I would really like is for the following to be possible, possibly falling back to `--update-with-dependencies` if it does not work.
```bash
$ composer-nodeless require --dev magento/magento-coding-standard:"15"
./composer.json has been updated
Running composer update magento/magento-coding-standard
Loading composer repositories with package information
Updating dependencies
Lock file operations: 0 installs, 1 update, 0 removals
- Upgrading magento/magento-coding-standard (8 => 15)
Writing lock file
Installing dependencies from lock file (including require-dev)
Package operations: 0 installs, 1 update, 0 removals
- Downloading magento/magento-coding-standard (15)
- Upgrading magento/magento-coding-standard (8 => 15): Extracting archive
```
Contributor guide
Research direction
Start with helpers/php/src/Updater.php around line 74, the location identified in the issue, and trace how Composer update commands are assembled. Compare the current dependency-update behavior with the requested command without --update-with-dependencies; done means the preference can request targeted updates while preserving the existing fallback behavior when needed.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- php
- Domain
- tooling
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 42/100