RangeError: Maximum call stack size exceeded with `.toBe` on a large string

🐛 Bug Report

    expect(["....big string here"]).toBe("another 3MB string");

Writing code like this, jest will throw RangeError, here is the error message:

  ● Test suite failed to run

    RangeError: Maximum call stack size exceeded
        at String.match (<anonymous>)

      at exports.separateMessageFromStack.content (node_modules/jest-message-util/build/index.js:368:32)
          at Array.map (<anonymous>)

the Array expect function got has an item that is an about 3MB string (base64 image), and toBe got the same base64 String.

To Reproduce

like above.

Expected behavior

should fail the test, but not throw range error

Link to repl or repo (highly encouraged)

envinfo

  System:
    OS: macOS 10.14.6
    CPU: (4) x64 Intel(R) Core(TM) i5-6267U CPU @ 2.90GHz
  Binaries:
    Node: 11.2.0 - ~/.nvm/versions/node/v11.2.0/bin/node
    Yarn: 1.12.3 - /usr/local/bin/yarn
    npm: 6.4.1 - ~/.nvm/versions/node/v11.2.0/bin/npm
  npmPackages:
    jest: ^23.6.0 => 23.6.0 

[StringEpsilon]

I’m not entirely sure if a unit test suite does that, but think a good way of dealing with overly long lines would just be to chop to the relevant section. That would be the start of the differences + whatever surroundings can be added reasonably.

Samples for comparing against SBjb21wcmVoZW5zaXZlIEphdmFTY3JpcHQgdGVzdGluZyBzb2x1dGlvbi4gV29ya3Mgb3V0IG9mIHRoZSBib3ggZm9yIG1vc3QgSmF2YVNjcmlwdCBwcm9qZWN0cy4K

Expected: "SBjb21wcmVoZW5zaXZlIEphdmFTY3JpcHQgdGVz" + [88]
Received: "_Z_Bjb21wcmVoZW5zaXZlIEphdmFTY3JpcHQgdGVz" + [88]

Expected: [66] + "Mgb3V0I_G9ml_HRoZSBib3ggZm9yIG1vc" + [31 ]
Receveived: [66] + "Mgb3V0I_G9ML_HRoZSBib3ggZm9yIG1vc" + [31]

Expected: [80] + "ZSBib3ggZm9yIG1vc3QgSmF2YVNjcmlwdCBwcm9qZWN0cy4_K_"
Received: [80] + "ZSBib3ggZm9yIG1vc3QgSmF2YVNjcmlwdCBwcm9qZWN0cy4_L_"

It’s not entirely uncommon for compilers or intrepeters to chop lines to the relevant section. I’m not entirely sure how much overhead this would introduce. I’m also not sure about the UX aspects of chopping strings that should be equal but aren’t (i.E. introducing headaches to the guy debugging that test)

[SimenB]

While it fails here https://github.com/facebook/jest/blob/736edd2ea6c9aadfb6e8794ecdc8a726f8a76b1a/packages/jest-message-util/src/index.ts#L358-L360, I think it makes more sense to avoid huge strings here: https://github.com/facebook/jest/blob/736edd2ea6c9aadfb6e8794ecdc8a726f8a76b1a/packages/jest-matcher-utils/src/index.ts#L307-L313 rather than trying to fix the regex part. This ends up generating a huge string, which is used when throwing the assertion error, which we later run the regex against. I think such a huge string is not useful anyways

That said, the change @StringEpsilon suggests seems reasonable regardless?