fix: Added catches for primitive/null values passed as "actual" in assertObjectMatch

[JakeAve]

Having issues when null and undefined are passed in the 'actual' argument for assertObjectMatch. Typeof null is 'object', so in recursion null kept being sent as a weakmap, but should have been assigned as filtered[key] = value.

Primitive types also could be passed in as the 'actual' value in JS, and they gave a cryptic weakmap error, but it's just a typeerror.

I slightly disagree with the AssertionError instead of the TypeError in issue #3451, but I'm open to suggestions.

[JakeAve]

I know that @luk3skyw4lker looked at this too. Can we get his blessing in case he has something better?

[luk3skyw4lker]

Hey @JakeAve maybe you should run the deno fmt command because there are many diffs that are mainly code formats and deno already has a pattern for code format.

[JakeAve]

@luk3skyw4lker I agree. @kt3k I'm on

deno 1.34.3 (release, aarch64-apple-darwin)
v8 11.5.150.2
typescript 5.0.4

but my deno fmt is changing a lot more lines than I feel like it should.

[kt3k]

@JakeAve I think these formatting changes were caused by your editor settings (do you enable any auto formatter?). Deno doesn't seem introducing these changes recently (and deno fmt allows/respects some formatting variations). Could you revert the change, disable auto formatter, and redo the actual changes?

[kt3k]

How about returning a here instead of throwing TypeError? That makes the case assertObjectMatch(null, { foo: 42 }) throwing more useful AssertionError instead of TypeError.

[JakeAve]

I'm open to that. I feel like assertObjectMatch is supposed to be for higher ordered objects, so I've been wanting to do a typeerror, but I understand you could have a function that returns either null/undefined or an object. The problem I have is there are ts warnings whenever you try to pass something that couldn't be made into a weakmap, so if we go that route, I wonder if we update the argument types to accept more values than

actual: Record<PropertyKey, any>,
expected: Record<PropertyKey, unknown>,

I'm pushing the updates so we can see how it looks.

[kt3k]

I feel like assertObjectMatch is supposed to be for higher ordered objects, so I've been wanting to do a typeerror

Ah, right. The previous version might make more sense. Thanks for the clarification of the reasoning.

[kt3k]

LGTM