assert: fix diff color output

[BridgeAR]

The color output was broken at some point and that was not detected
because it was not tested for properly so far. This makes sure the
colors work again and it adds a regression test as well.

Checklist

• make -j4 test (UNIX), or vcbuild test (Windows) passes
• tests and/or benchmarks are included
• documentation is changed or added
• commit message follows commit guidelines

[BridgeAR]

CI https://ci.nodejs.org/job/node-test-pull-request/13753/

[mcollina]

LGTM

[BridgeAR]

Rebased due to conflicts.

New CI https://ci.nodejs.org/job/node-test-pull-request/13856/

[mcollina]

LGTM

[BridgeAR]

Landed in 2e6dd93

[targos]

Should this be backported to v9.x-staging? If yes please follow the guide and raise a backport PR, if not let me know or add the dont-land-on label.

[jasonkarns]

Should those color values be calculated just once instead of on every AssertionError instantiation?

The comment Reset on each call to make sure we handle dynamically set environment variables correct. Is this only for node's own test suite?

When else would those env vars change after the first AssertionError?

[BridgeAR]

@jasonkarns it is theoretically possible to change environment settings at any point of time. As far as I know there is no rule so far about when to check for environment settings. There are multiple possibilities:

1. Check on startup and keep it that way.
2. Check on first use and keep it that way.
3. Check on each use.

In this case I decided to go for the latter without having a strong opinion on either case. Do you see a downside in this specific behavior?

[jasonkarns]

@BridgeAR yep, theoretically possible since of course anything under process. is mutable :D Just seems that practically speaking, these assertions will be used primarily for test suites, and it would be extremely unlikely for the system under test to modify those values in between tests.

The only downside is just the "waste" of recalculating those values when, in practice, they'll never change. Almost more valuable is the code cleanliness of just having them defined once as consts at the top: 7914a34#diff-5a3344c263a73c663dd1cfcb91880fd7R18

I'm typically on team "don't pre-optimize". But in this case it just feels weird to have the code contort and be defensive about such a scenario.

🤷‍♂️

[BridgeAR]

@jasonkarns the overhead for this is pretty tiny compared to creating the stack trace etc.

I checked our code base again and in most cases we check the env on each use. Since there is no rule to it so far we should likely keep this behavior in place (what ever reason a user might have to change the environment variables during runtime).