Skip to content

"Non-POJO" check is slightly naive #5

@Conduitry

Description

@Conduitry

First, a disclaimer: This issue is niche as hell. I understand that. But:

If a POJO was created in a different context, checking whether its prototype is Object.prototype will fail, because its prototype is actually a different Object.prototype. This actually did come up for me, when I was trying to stringify a value created by Node's vm module. You can easily reproduce this by attempting to run devalue(vm.runInNewContext('({})')).

Now. I don't really know what a good solution to this is, and it seems it's likely that I need to send normal object to devalue more so than that devalue needs to handle weird ones.

One heavy-handed way would be to have an option that forces devalue to stringify objects, regardless of whether it perceives them to be non-POJOs.

A less heavy-handed way (but kind of a weird one) would be to have an option that can be passed to devalue that tells it what Object or Object.prototype object to use.


In the other sort of direction, devalue currently silently ignores any keys on objects that are non-enumerable or that are a symbol and not a string. By their very nature, there's no way to handle symbol keys - and it might be possible to deal with non-enumerable ones but it's likely to not be worth the hassle. Anyway, perhaps these should throw exceptions rather than just being ignored.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions