initial thoughts

[boneskull]

@DerekNonGeneric I'm not sure what exactly you're looking for, but here's this:

• operator is probably far too limiting to be of use past trivial comparisons such as ===, >, !==, etc. Other comparisons such as regex matches, deep object equivalence, deep property comparisons or compound assertions won't have much use for it.
• Many of the mentioned properties in the ecosystem's AssertionError implementations are framework-specific. It's clear from the proposal that this is understood, but bears repeating.
• IMO contextual information about the difference between actual and expected is absolutely necessary for any framework to make use of an AssertionError. I believe this was the intent behind operator, but again, I think that's insufficient. For example, we could be checking that object foo and object bar are not strictly equal. operator may be sufficient for this case, but without anything else, it cannot be expressed by just actual and expected--these properties may be useless at best and misdirection at worst. So it's the responsibility of whatever is throwing the AssertionError to put enough information in there that the consumer (a test framework perhaps) can display a representation. For that reason, a free-form difference property makes sense to me. This could be structured data or just a string; it will probably be difficult if not impossible to define/standardize a structure which would represent any "assertion" which can fail. At any rate--something else is needed.
• In the case of "compound" assertions (e.g., array foo contains object bar and has length 4), an assertion library may make both of these checks; if the first fails, it may not short-circuit the assertion. These failures would be combined into a single AssertionError then thrown. Is it possible to leverage the newish cause prop here, though it looks more like a linked list than "(potentially) multiple causes", so maybe not applicable?

("assertion libraries" above also means "assertion subsystems of testing frameworks")

[DerekNonGeneric]

• operator is probably far too limiting to be of use past trivial comparisons such as ===, >, !==, etc. Other comparisons such as regex matches, deep object equivalence, deep property comparisons or compound assertions won't have much use for it.

“relational or equality” operators, such as <, <=, >, >=, ==, etc. should definitely be considered for this, but there are also “identity and membership” operators like is or in that can also be considered for this… I think we can (and probably should) expand upon this in the proposal explainer (currently the readme file).

[boneskull]

@DerekNonGeneric How do you mean? I guess I'm not convinced the notion of an "operator" is any finite set of values, let alone one that can be standardized. For example, what if my assertion is "the STDOUT of this command-line app, when parsed into JSON, is equal to {foo: 'bar'} and the exit code was greater than zero?" (And yes, this can be a single assertion)

[DerekNonGeneric]

Okay, i actually didn't mean to disagree w/ you and see what you're saying now. I guess regarding that bullet point, we can't really say what that property would contain, but might want to be sure it exists?

[boneskull]

@DerekNonGeneric I guess I'd feel better if it was optional. Assuming operator is intended to be either a) a concise representation or b) a machine-readable representation, generating the value may be non-trivial; e.g., a hierarchical data structure or a DSL.

I mean--I guess it's a big ask for assertion libs that have composable assertions, as well as any ecosystem of plugins around those libs. Should we be considering the difficulty of adoption?