fix: function name should be obtained from next frame’s position

[JLHwung]

This is a follow-up to #220.

In #220 we provided position.name before stack.getFunctionName to support mangled function calls. However, stack.getFunctionName is supposed to return the name of the current function, that is, which function does this frame live in. Regards to the source map, it is the name of the position in next frame instead of in this frame.

To illustrate this issue, here is a reproducible repository I revised from babel/babel#9883:

function foo() {
  console.log(new Error().stack);
}

function bar() {
  foo();    // <-- Here we are supposed to get `bar` as function name but instead get `foo`.
}

bar();

The expected output should be

    at foo (/Users/jh/code/babel-sourcemap-bug/src/index.js:2:15)
    at bar (/Users/jh/code/babel-sourcemap-bug/src/index.js:6:3)
    at Object.<anonymous> (/Users/jh/code/babel-sourcemap-bug/src/index.js:9:1)
   // <--- frames below are omitted --->

The current output after requiring source-map-support/register is

    at foo (/Users/jh/code/babel-sourcemap-bug/dist/src/index.js:2:15)
    at foo (/Users/jh/code/babel-sourcemap-bug/dist/src/index.js:6:3)
    at Object.<anonymous> (/Users/jh/code/babel-sourcemap-bug/dist/src/index.js:1:1)
    // <--- frames below are omitted --->

Apparently foo is incorrectly repeated.

To fix this issue, we reverse the stack processing order and introduce internal state to track next frame position. As wrapCallSite is exported as a public API, I would consider this change as a breaking change.

[JLHwung]

@LinusU ping :) This is an upstream issue of babel. Are there anything I can help?

[LinusU]

Sorry for the delay, I've been out traveling and my inbox is a mess right now 😅

[LinusU]

Released as 0.5.14

[JLHwung]

@LinusU Cool. Was it also published to npm?

[LinusU]

Was it also published to npm?

🤦‍♂

It is now! ☺️

[SimenB]

This broke function names in Jest's stack traces. Using 0.5.13 we get e.g. at Object.toThrowCustomAsyncMatcherError (__tests__/asynchronous.test.js:11:16), and with 0.5.14 we get at Object.<anonymous>.test (__tests__/asynchronous.test.js:11:16). A bunch more examples in https://circleci.com/gh/facebook/jest/73294.

Any idea if we can change anything in Jest to fix it, or was this an honest regression?

(0.5.16 makes no difference, fwiw)

EDIT: I've opened a separate PR just for source-map-support showing it's the only change and tests fail. Master is green. jestjs/jest#9147

[LinusU]

@SimenB I think that @JLHwung answered this in jestjs/jest#9147, please let me know if there is anything more that should be done from our side though, I'll try and stay up to date in that thread as well