✅ Deploy Preview for docs-eslint canceled.

I'm not sure if I would agree with the described motivation since I believe the expected values should be specified based on expectations for the test case rather than copied from the actual values, but I'm fine with this change as I think it can be helpful for debugging to output the full actual location when at least one part of it doesn't match the expected value.

@eslint/eslint-team thoughts?

Oh! I actually like this a lot. Agreed that the expected values should be specified based on expectations for the test case rather than copied from the actual values. But also, changes to a rule's report range are quite tedious to reflect in tests. I've had to repeatedly go through passes of changing first one property, then another, etc. This would help.

I'm personally 👍 to this change.

I usually use Node.js's native test runner for my custom packages, and it shows less verbose error messages than mocha.

So, I think this change would help users who use less verbose test runners for their tests.

In my opinion, it would be nice to slightly beautify and summarize the newly added error message.

In my opinion, it would be nice to slightly beautify and summarize the newly added error message.

Any suggestions?

Maybe:

AssertionError [ERR_ASSERTION]: Error endLine should be 8 - Actual: { line: 7, column: 16, endLine: 7, endColumn: 20 }

?

If the desire here is to treat the location as one atomic unit then I don't think this is the right solution. Here, we're still checking the location one field at a time and the only difference is outputting all four fields...but you're still only telling people that one field is incorrect. Including the other three fields in the message doesn't mean anything because they could all be correct, all be incorrect, or something in between.

If we really want to make a change here, then it should be to treat the four fields as one unit that are validated together and the failed assertions are shown together.

I agree with @nzakas — the correct approach should be to treat the location fields as a single unit and validate them together, showing the actual vs expected values. That said, I'm unsure whether this change would be considered breaking or not.

Treating it as a single unit would require validating all or none fields.

assert.equals(
  { line: message.line, column: message.column, endLine: message.endLine, endColumn: message.endColumn },
  { line: error.line, column: error.column, endLine: error.endLine, endColumn: error.endColumn }
)

I'm fine with that, but that would probably be more breaking than the error message of the method used to validate errors/messages.
I assume, nobody is checking the failure messages, only whether the rule tester passes or fails.
However, I think quite a few tests/devs only verify a few/subset of the location properties.

@ST-DDT that's not a problem, we can always check to see which of the location properties is present and only check those properties.

Changing the assertion message output isn't a breaking change. It would only be breaking if we ended up checking a value that wasn't previously checked, which is not what we're doing.

Do we still show all actual location properties?
Or only those that are already present?
I would prefer showing all.

Only those that are present. What we should do is create an object with the properties that are defined in the test case, then create an object with the expected values for each property, then run assert.deepStrictEqual() on those objects to get the desired output.

Switched to the default assertion output.

Side question: What is the contributor pool? The label doesn't have a description.

Side question: What is the contributor pool? The label doesn't have a description.

We use this label to mark PRs that are considered for payment to contributors. For example:

https://github.com/eslint/tsc-meetings/blob/main/notes/2025/2025-06-12.md#contributor-pool-may-2025