Feature Request - set different options for different filtered packages in a single configuration file

[ath0mas]

Feature Request - group different sets of options with their corresponding filter in a single .ncurc.json

I envoy using ncu with its default configuration file .ncurc.json to call it with a unique and basic command, ncu, without any cli option, so that anyone in my team can run it without the need to know what are our options.

Given we have some internal dependencies, released more frequently and with prerelease versions, we need to know when such dependencies in our main scope are published. So, I add pre: 1 to most of our .ncurc.json.
The main drawback is that ncu will use this rule for all the dependencies and not only the ones we really want to track.

I understand that filter and reject are the right answer for me ; and that I could group these different sets of options in separated configuration files.
So, I could then make different calls targeting each:
ncu --configFileName .ncurc.foo.json, ncu --configFileName .ncurc.bar.json, ...
But back to requiring everyone in the team to know of our options, or to merging these commands in a single one, for example through package or bash scripts.

➡️ Please, could it be allowed to have a list of configurations in a single configuration file, instead of 1 configuration in 1 file for each of the configurations?

---

Something like:

.ncurc.json

{
  "upgrade": true,
  "deprecated": true,
  "target": "latest",
  "overrides": [{
    "filter": "@myorga/*",
    "target": "newest",
    "pre": 1,
  }, {
    "filter": "tslint",
    "deprecated": false,
  }],
}

merging between main and overrides, like what does --mergeConfig 🤔

[raineorshine]

The way we enabled per-dependency targets was to add support for a custom target function. Would adding support for a custom pre function solve your use case?

e.g. .ncurc.js

module.exports = {
  pre: (name, version) => name.startsWith('@myorg') ? 1 : 0
}

[ath0mas]

Using a a custom pre function would do it yes I think.
But I also really think it would be better to be able to group configs for a pattern or function filter, instead of implementing new custom functions for each of the configs one after another, and in my case, having to repeat same filtering logic multiple times.

[raineorshine]

That's a good point. I do like the more declarative structure of overrides. The most common use case is likely a simple filter on the dependency name or org, which is easier to express in overrides.

For the implementation, I would suggest merging the options as soon as soon as the program enters package-specific logic, i.e. at the top of getPackageVersionProtected. Then the downstream handling of specific options doesn't have to know about the overrides logic. They will just receive options as usual, but version-specific overrides will already be merged.