Steve Gravrock

Thanks for the report. This sort of thing will help inform whether and when we can stop having a separate CommonJS module loading path. (My guess is that we won't...

Thanks for the info. I think `jsLoader: "require"` is the right solution, but we could probably produce a more helpful error message in this situation.

The problem is that `Loader` isn't nearly stable enough to be part of the public API. In particular, there's been a lot of change recently to how it interacts with...

The short answer is that there isn't currently a good way to test a custom matcher in integration with `MatchersUtil` and `pp`. If you're trying to unblock a migration to...

The one gotcha with matchers that throw exceptions when they fail is that they don't work with `.not` unless they have a `negativeCompare` method. `.not` inverts returned matcher results but...

Closing, since this has clearly failed to reach consensus. I tend to agree with the philosophical objections to this feature. More importantly, the problem of misleading messages from custom matchers...

Thank you for the PR. I'm sorry you didn't get a response much sooner. This is impressive work, but I'm not planning to merge it. The async loop transformation adds...

Closing since this has long since been overtaken by changes in jasmine-ajax, jasmine-core, and likely the front end development ecosystem. We haven't heard anything about CommonJS in the browser in...

Agreed. I think this is too niche to directly support. [`throwUnless`](https://jasmine.github.io/api/5.1/global.html#throwUnless) handles the general case of testing that matchers integrate with Jasmine's equality system etc. correctly. The other option, for...

I'm closing this due to prolonged inactivity, but anyone who wants the proposed change enough to implement it should still feel free to submit a PR.