Modules required with sandboxed-module do something weird with prototypes.

[tandrewnichols]

I tried to browse the code to see what exactly, but I decided it would be faster to surface the issue here and see if it's expected behavior. Maybe I'm just using this module wrong (or misunderstanding something).

I've noticed that some testing frameworks have problems in conjunction with this module. See this gist for an example: https://gist.github.com/tandrewnichols/9446085.

Below is the output from running npm test on that code (minus stack traces):

> mocha fooBar.coffee --ui mocha-given --compilers coffee:coffee-script/register --reporter spec

should is defined: { obj: {} }

  foo
@subject.foo is: {}
    1) then console.log('@subject.foo is:', this.subject.foo); return this.subject.foo.should.eql({

  bar
@subject.bar is: []
    2) then console.log('@subject.bar is:', this.subject.bar); return expect(this.subject.bar).to.deep.equal([])

  0 passing (15ms)
  2 failing

  1) foo then console.log('@subject.foo is:', this.subject.foo); return this.subject.foo.should.eql({:
     TypeError: Cannot call method 'eql' of undefined

  2) bar then console.log('@subject.bar is:', this.subject.bar); return expect(this.subject.bar).to.deep.equal([]):

Changing sandbox 'fooBar' to require './fooBar' makes the code pass. Also, wrapping @subject.foo and @subject.bar in JSON.parse(JSON.stringify(...)) makes them pass. Is some additional property being added that would make traditional comparisons fail?

[domenic]

Indeed, sandboxed modules are completely sandboxed; objects in them live in a different global context, with different prototypes etc.

[tandrewnichols]

I forgot this was still open. Yeah, I actually realized that later, as I looked at what vm is doing. Thanks.