Revert "vm: support parsing a script in a specific context"

[MylesBorins]

This reverts commit 7d95dc3.
It causes breakages in the Browserify test suite

I want to land this in less than 48 hours as it is blocking the release of 8.7.0

[addaleax]

This seems like a combination of bugs in browserify’s dependencies and its test suite – nothing that you would run into when you’re just using browserify for its purpose? I don’t think the PR in question is semver-major and it doesn’t look to me like we’d need to revert this.

(edit: Maybe it’s obvious from the above but I also don’t think we should hold up 8.7.0 over this…)

[MylesBorins]

@addaleax the failures come from a buggy Traceur polyfill for object.assign

#14888 (comment)

My concern is that while this may not technically be Semver-Major it will potentially break things in the ecosystem that were working in 8.6.0

Open to discussion on this if people are all on the same page. Would like to see browserify's test suite fixed as well, but perhaps we can keep this commit and prioritize that instead

[addaleax]

Yeah, but the failures also appear only in a new vm context as far as I can tell (or otherwise they would already be happening anyway?), which is the bit that’s specific to browserify’s test suite and that will not happen when the actual browserified code is run in a, well, browser…?

[TimothyGu]

I'm -1 because I am still not convinced a buggy test in a basically under-maintained test suite is worth reverting a Core change. (Note: Browserify still works!)

If that is not convincing enough of a reason, one can just cache Object.assign at the beginning of the file, and call the saved function. That is purely an ad-hoc fix, especially since the rest of the code base uses Object.assign() with no problem, but if that makes @MylesBorins happier I'm okay with it.

[fhinkel]

Not in favor of reverting.

[jasnell]

I'm also -1 on reverting

[MylesBorins]

Closing revert... Will work on getting browserify test suite fixed