TypeError: Cannot convert undefined or null to object about mingo HOT 9 CLOSED

I've experienced the same or at least a similar bug in my nextjs application. I've already analyzed it a bit, but haven't opened a PR because I haven't been able to extend the test cases for testing my fix, nor have I been able to provide a simple reproduction environment for the bug.

What I've found so far is that the bug was introduced in v6.4.7 and it occurs in the isTypedArray function.
I did some digging and found out that my build environment overwrites the [Symbol.toStringTag] of an object that is a module (e.g. Object.defineProperty({ ... }, Symbol.toStringTag, { value: "Module" })). This breaks the isObject check and therefore the code calls the isTypedArray function from cloneDeep.

A possible fix would be to test if the constructor is defined:

const isTypedArray = (v: AnyVal): boolean => {
+  const ctor = getConstructor(v);
+  const proto = ctor && Object.getPrototypeOf(ctor) as Callback;
-  const proto = Object.getPrototypeOf(getConstructor(v)) as Callback;
  return proto && proto.name === "TypedArray";
};

But this will only fix the symptom of the error, not the root cause which is in isObject.
My current workaround was to downgrade to v.6.4.6

from mingo.

I've just tested through all the versions and the latest working one for our case seems to be 5.1.0

from mingo.

Okay, then it might be a different bug in my case

from mingo.

I will mention that we tracked it down to the same function, it is definitely the build environment messing with that module.

from mingo.

Thanks @eonkleynhans for reporting this issue. Doing a quick comparison between versions, the isObject function hasn't changed since 5.1.0. The isTypeArray function is recent addition to support deep cloning typed arrays when present.

There is a guard to ensure null and undefined values aren't passed directly to Object.getPrototypeOf by delegating to internal classes Null and Undefined to represent them. This ensures their constructors always exist.

Besides those two, I am unaware of an object in JS that would not have a constructor.

Can you confirm whether the transpiled JS maintains all checks?

from mingo.

It's possible to actively overwrite the prototype or set it to null. It seems that vite is doing something like that for modules:

I've put the reproduction example from @eonkleynhans, mentioned in the first post, in a repository to make testing easier: https://github.com/maxnowack/mingo-reproduction-390

from mingo.

Refactoring the isObject method to also work on these types of objects is a bit hard and I wasn't able to figure out a general solution for that.
Spreading the imported [object Module] into a plain object when calling useOperators resolves the TypeError.
I proposed a fix in #391

from mingo.

As I mentioned here, the TypeError was already fixed by 254afa6

from mingo.

@kofrasa don't forget to publish the changes to npm 🙂

from mingo.