Additive configuration is broken in some instances.

[jason0x43]

In Intern 4.1.5, having a config with "reporters+": "htmlcoverage" will result in only htmlcoverage being active in the Node executor, when the default runner reporter should also be active. The issue is that config data is being resolved by getConfig rather than the executor's own config method, so the executor ends up missing some useful information (like the presence of the '+' indicator).

[jason0x43]

The expected result is that htmlcoverage is added to the default reporter (runner).

[aciccarello]

So it would be complicated to rework the config loading to return the addToExisting property since it is dependent on config order. Even if the addToExisting was retained, you would need to also pass each level of config and reimplement to logic to combine them. This is because the main config may be additive but then the child config could completely override it.

Config load order (simplified)

1. Defaults (needed)
2. Extended
3. Main
4. Child (node/browser)
5. Args

In order to support defaults like the reporter, the config loader should take a default config argument. This would probably need to be a breaking change since the config loading functions already have multiple optional params and the loadConfig() function is publicly exposed.

Relevant files in loading config:

• bin/intern.ts which requests the config and sets it on intern
• lib/node/util.ts getConfig()
• lib/common/util.ts loadConfig() and the recursive implementation function _loadConfig()

[jason0x43]

Would the default config then take the place of the defaults being applied by the executors? That would simplify things, particularly around the handling of default reporters.

As far as breaking changes go, we can tolerate them for Intern 5-pre (yay major version change). It may be worth considering how we could minimize those in the future, though, possibly through more use of options objects vs additional discrete arguments.

[jason0x43]

Closing this in favor of #1109