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

fix: extends not working for some settings #4980

Open
wants to merge 3 commits into
base: master
Choose a base branch
from

Conversation

manuth
Copy link

@manuth manuth commented Apr 24, 2023

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:

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):

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

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

@manuth manuth changed the title Fix extends Fix Extends not Working for Some Settings Apr 24, 2023
@github-actions
Copy link

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!

@github-actions github-actions bot added the stale this has been inactive for a while... label Aug 25, 2023
@manuth
Copy link
Author

manuth commented Aug 25, 2023

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

@github-actions github-actions bot removed the stale this has been inactive for a while... label Aug 28, 2023
@JoshuaKGoldberg
Copy link
Member

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

@JoshuaKGoldberg JoshuaKGoldberg added the semver-major implementation requires increase of "major" version number; "breaking changes" label Mar 1, 2024
Copy link
Member

@JoshuaKGoldberg JoshuaKGoldberg left a comment

Choose a reason for hiding this comment

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

Seems good and reasonable, nice! 🔥

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

var loadOptions = require('../../lib/cli/options').loadOptions;

describe('options', function () {
var workingDirectory;
Copy link
Member

Choose a reason for hiding this comment

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

[Question] Is there a reason not to make this set only once? Does it have to be set before each test?

Suggested change
var workingDirectory;
const workingDirectory = process.cwd();

Copy link
Author

Choose a reason for hiding this comment

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

Whenever I change directories for performing tests, I use to always restore the previous working directory in order to not have it interfer with other tests and beforeEach functions.

I could entirely drop it or replace it with beforeAll/afterAll

Copy link
Member

Choose a reason for hiding this comment

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

[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.


config = yargs(undefined, path.dirname(filepath))
.parserConfiguration(require('./options').YARGS_PARSER_CONFIG)
.config(config);
Copy link
Member

Choose a reason for hiding this comment

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

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.

Copy link
Member

Choose a reason for hiding this comment

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

[Non-Actionable] These tests look like they're a continuation of the code in #4407. I.e. their code was partially written by @mf-pherlihy in #4407. I added in a Co-authored-by attribution at the bottom of the PR description. Just a heads up. 🙂

Copy link
Author

Choose a reason for hiding this comment

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

I indeed borrowed the code from there, I'll keep that in mind in case I'll contribute to mocha again.
Thanks a lot for taking care of that 😄

@JoshuaKGoldberg JoshuaKGoldberg added the status: waiting for author waiting on response from OP - more information needed label Mar 1, 2024
@JoshuaKGoldberg
Copy link
Member

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

@JoshuaKGoldberg JoshuaKGoldberg changed the title Fix Extends not Working for Some Settings fix: extends not working for some settings Mar 4, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
semver-major implementation requires increase of "major" version number; "breaking changes" status: waiting for author waiting on response from OP - more information needed
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants