Support Dates

[ethanresnick]

This is a continuation of #16.

To detect Dates, it uses a variant of the most recent strategy proposed by @ericf at #16 (comment). Using that strategy also suggested some tweaks to make the type detection mechanism more robust if Function.prototype.toJSON or RegExp.prototype.toJSON has been set (see commit message).

[yahoocla]

Thank you for submitting this pull request, however I do not see a valid CLA on file for you. Before we can merge this request please visit https://yahoocla.herokuapp.com/ and agree to the terms. Thanks! 😄

[ethanresnick]

CLA signed!

[ethanresnick]

@ericf Are you still involved with this library? If so, can you take a look at this? I'd love to see it merged!

[caridy]

potential maintainers: @okuryu @juandopazo

[okuryu]

sure. I'll take a look it.

[okuryu]

@redonkulus please add me into git and npm permissions.

[redonkulus]

@okuryu done for both

[okuryu]

Thanks!

[okuryu]

👍

[ethanresnick]

@xumx If I understand correctly, the second serialize call is failing because the RegExp global in your sandbox is different than the RegExp global outside it, right? I.e., it's a cross-realm issue.

I see a few options here:

1. We can switch from the instanceof Date and instanceof RegExp checks back to util.isDate and util.isRegExp. I'd moved away from those functions, though, because they're deprecated in Node (though I don't know the story behind why.)

2. We can switch to user-land implementations of util.isDate and util.isRegExp that work around the cross-realm issue (idk how reliably), like https://github.com/ljharb/is-regex and https://github.com/ljharb/is-date-object

3. You could pass the external RegExp and Date globals into your sandbox—ideally wrapped in a proxy somehow so that the sandbox can't mutate them—so that deserializing creates RegExps and Dates that share the same globals as the context where the deserialized value will be used. (Or just use eval.) Either of those approaches might be a security issue (idk really what the vm module's sandboxing gives you), but it would stop instanceof checks from failing in the code that uses the deserialized values, which is probably a good thing. [Also, as an aside, if this library intends to support deserialization with methods other than eval, it'd be good to have tests for that.]

[caridy]

Identity discontinuity is a real pain. I don't think providing expansion slots of any kind will help here because we also serialize functions, and if those functions are parsed and evaluated in a different realm, the objects that they produce (imagine that the function returns a regexp) will always exhibit different identity. The solution must be in user-land by evaluating the code in the correct sandbox, or work around the identity discontinuity problems.

Side Note: Unfortunately we don't have realms in the language yet (coming soon).

[ethanresnick]

Continuing this in #31...