fix: extends not working for some settings

[manuth]

Requirements

• Filling out the template is required. Any pull request that does not include enough information to be reviewed in a timely manner may be closed at the maintainers' discretion.
• All new code requires tests to ensure against regressions.

Description of the Change

As described in issue #4979, due to mocha first loading its default settings and after doing so processing the arguments using args, there are some settings which cannot be inherited by specifying an extends file:

• First, default values get loaded:
  

  mocha/lib/cli/options.js

  Line 246 in 37deed2

  args = parse(args._, mocharc, args, rcConfig || {}, pkgConfig || {});

• Sometime later, the configuration gets processed:
  

  mocha/lib/cli/cli.js

  Line 77 in 37deed2

  .config(args)

Changes made in this PR processes configuration files using yargs right after they have been parsed. Thus, the order of events is now the following:

• RC files are parsed
  • RC files are processed using yargs
• package.json settings are loaded
• Collected configs and argv get merged
• mochas default values (from lib/mocharc.json) get applied

Alternate Designs

Configuration files could be processed right before mochas defaults get applied. However, the context of the file path would get lost thus causing relative extends paths to possibly fail.

Applying mochas default values could be removed from here:
https://github.com/mochajs/mocha/blob/37deed262d4bc0788d32c66636495d10038ad398/lib/cli
And instead be done somewhere around here (after yargs has been executed):

mocha/lib/cli/cli.js

Line 47 in 37deed2

var args = mochaArgs || loadOptions(argv);

Why should this be in core?

Currently, the inheritance will not work for a number of settings while other settings do. This might cause confusion and unexpected results. Thus, I'd recommend to have this change in core.

Benefits

All settings will be able to be inherited while mochas defaults still get applied if necessary.

Possible Drawbacks

None that I have heard of.
If people already used extends for their own project, there is a chance that they relied on the inheritance of ui to not work, so there is a small possibility they will have to perform a one-time change to their config file.

Applicable issues

• Enter any applicable Issues here.

  • 🐛 Bug: Some Settings Cannot Be Inherited (extends keyword) #4979
  • 🐛 Bug: Configurations don't seem to support 'extends' #3916
  • Original PR: fix: fully support 'extends' for configurations #4407

• Mocha follows semantic versioning: http://semver.org

• Is this a breaking change (major release)?

• Is it an enhancement (minor release)? (Maybe?)

• Is it a bug fix, or does it not impact production code (patch release)?

Or probably a minor as there is a small possibility people have to adjust their configuration if they used extends before

Co-authored-by: Pat Herlihy @mf-pherlihy

[github-actions]

This PR hasn't had any recent activity, and I'm labeling it stale. Remove the label or comment or this PR will be closed in 14 days. Thanks for contributing to Mocha!

[manuth]

Just pinging to have the stale label removed
I'd really love to see this implemented

[JoshuaKGoldberg]

Note: #4407 also touches this area. We should review them together in case one is a dup.

[JoshuaKGoldberg]

Seems good and reasonable, nice! 🔥

Marking as requesting changes just so we can chat about the two possible implementations a bit.

[JoshuaKGoldberg]

[Praise] As with #4407's tests, these are nice! I like that this also has an added second one for both --config and file coverage.

[JoshuaKGoldberg]

Noting https://github.com/mochajs/mocha/pull/4407/files#r1509449877 here: would be nice to have discussion on which API option to use. I'm leaning towards this one, but want to hear if there are advantages to applyExtends I missed.

[JoshuaKGoldberg]

Oh darn I wasn't very clear on this. I wanted to ask you @manuth as well as @mochajs/maintenance-crew, does anybody have opinions on using this API vs. yargs/helpers -> applyExtends? I'm in favor as-is, but since two PRs tried two different approaches I think I'd want to see if anybody prefers the other approach.

[manuth]

I'm not entirely sure anymore why I decided to use this function instead.
I remember that when using a different approach, some options were overridden by default.

I will read through my commit messages during the upcoming weekend. I really hope I can reproduce my thoughts this way.

[JoshuaKGoldberg]

👋 just checking in @manuth, anything I can help with?

[JoshuaKGoldberg]

Marking as semver-major because some projects might accidentally be relying on the current, arguably broken behavior.

Conversations resolved.