Jest vs Bazel: Something is broken

[hurryabit]

Running the test in the new project via yarn test works just fine.
However, running the same tests via

bazel test //language-support/ts/jest_vs_bazel:test

doesn't work. The test fails because it thinks the ws.server object
is not an instance of class Server. This clearly contradicts the
implementation of the WS class at
https://github.com/romgain/jest-websocket-mock/blob/eb8324ff0d4fd1a09effd994cba142f240fb8f7a/src/websocket.ts#L48

My suspicion is that bazel somehow brings multiple versions of the
Server class from mock-socket into scope. If you drill into
node_modules/mock-socket, you'll see that package.json lists
"main": "./dist/mock-socket" and there are five files in dist:

• mock-socket.amd.js
• mock-socket.cjs.js
• mock-socket.es.js
• mock-socket.es.mjs
• mock-socket.js
  The is also src/index.js which exports a Server class. So, there's
  plenty of ooportunity for bazel to get confused.

Despite that, I wonder how jest gets it right on its own but bazel
manages to confuse jest to get it wrong under bazel's guidance.

CHANGELOG_BEGIN
CHANGELOG_END

Pull Request Checklist

• Read and understand the contribution guidelines
• Include appropriate tests
• Set a descriptive title and thorough description
• Add a reference to the issue this PR will solve, if appropriate
• Include changelog additions in one or more commit message bodies between the CHANGELOG_BEGIN and CHANGELOG_END tags
• Normal production system change, include purpose of change in description

NOTE: CI is not automatically run on non-members pull-requests for security
reasons. The reviewer will have to comment with /AzurePipelines run to
trigger the build.

---

This change is 

[aherrmann-da]

I've been able to reproduce this issue in isolation https://github.com/aherrmann/mock_class_mismatch using vanilla rules_nodejs-1.1.0. So, this should not be related to any specifics of the daml repository.

I've used the following --node_options to try and trace module loading.

        "--node_options=--trace-event-categories=node",
        "--node_options=--trace-event-file-pattern=/tmp/node-trace-$${pid}-$${rotation}.log",

According to the output we are consistently loading the common-js versions under yarn

node_modules/jest-websocket-mock/lib/jest-websocket-mock.cjs.js
node_modules/mock-socket/dist/mock-socket.cjs.js

while loading mixed versions under Bazel

node_modules/jest-websocket-mock/lib/jest-websocket-mock.cjs.js
node_modules/mock-socket/dist/mock-socket.js

However, this does not seem to be the cause of the issue. I've patched the node_modules such that only the common-js versions are available and the same trace flags as above confirm that then also under Bazel only common-js versions are loaded. Nonetheless, the issue persists.

According to jestjs/jest#2549 using instanceof is problematic under Jest, because Jest runs tests under a sandbox context where classes can differ from their versions under the global Node context. The issue mentions differences between node versions. I have confirmed that the tests pass using yarn with node version 13.7.0 but fail under bazel with the same node version. I've also tried the SingleContextNodeEnvironment workaround described in that issue, sadly without success. It is still unclear why the tests pass under yarn but fail under bazel.

[hurryabit]

@aherrmann Thanks for the progress report. Great work! This seems to be a very dire problem. 😿

Regarding instanceof in jest, we should not be affected by this issue since the Server class is not coming from node but from one of the packages.