ts-jest: Line numbers are shown incorrectly when importing library that has default export

Same here with

    "jest": "^24.9.0",
    "ts-jest": "^24.1.0",

I fixed it by adjust the tsconfig.json. I had "mapRoot": "src/", in it, after removing the line numbers were correct. Also make sure to not load somewhere the module source-map-support manually.

Hi @kulshekhar, I think I got the reason why jest is reporting wrong line numbers in my tests.

Original source

it('toBoolean should return true for true/on/yes/1 values', () => {
    expect(toBoolean(true)).toBe(true);
    expect(toBoolean(1)).toBe(true);
    expect(toBoolean('true')).toBe(true);
    expect(toBoolean('truE')).toBe(true);
    expect(toBoolean('True')).toBe(true);

    expect(toBoolean(' true ')).toBe(true);
    expect(toBoolean(' truE ')).toBe(true);
    expect(toBoolean(' True ')).toBe(true);

    expect(toBoolean('yes')).toBe(true);
    expect(toBoolean('yes')).toBe(true);
    expect(toBoolean('Yes')).toBe(true);

    expect(toBoolean(' Yes ')).toBe(true);
    expect(toBoolean(' YES ')).toBe(true);
    expect(toBoolean(' YES ')).toBe(true);

    expect(toBoolean('1')).toBe(true);
    expect(toBoolean(' 1')).toBe(true);
    expect(toBoolean(' 1 ')).toBe(true);

    expect(toBoolean('on')).toBe(true);
    expect(toBoolean('On')).toBe(true);
    expect(toBoolean('oN')).toBe(true);
    expect(toBoolean(' on ')).toBe(true);
    expect(toBoolean(' On ')).toBe(true);
    expect(toBoolean(' oN ')).toBe(false); // error
  });

Generated source (from jest cache source directory)

 it('toBoolean should return true for true/on/yes/1 values', function () {
        expect(utils_1.toBoolean(true)).toBe(true);
        expect(utils_1.toBoolean(1)).toBe(true);
        expect(utils_1.toBoolean('true')).toBe(true);
        expect(utils_1.toBoolean('truE')).toBe(true);
        expect(utils_1.toBoolean('True')).toBe(true);
        expect(utils_1.toBoolean(' true ')).toBe(true);
        expect(utils_1.toBoolean(' truE ')).toBe(true);
        expect(utils_1.toBoolean(' True ')).toBe(true);
        expect(utils_1.toBoolean('yes')).toBe(true);
        expect(utils_1.toBoolean('yes')).toBe(true);
        expect(utils_1.toBoolean('Yes')).toBe(true);
        expect(utils_1.toBoolean(' Yes ')).toBe(true);
        expect(utils_1.toBoolean(' YES ')).toBe(true);
        expect(utils_1.toBoolean(' YES ')).toBe(true);
        expect(utils_1.toBoolean('1')).toBe(true);
        expect(utils_1.toBoolean(' 1')).toBe(true);
        expect(utils_1.toBoolean(' 1 ')).toBe(true);
        expect(utils_1.toBoolean('on')).toBe(true);
        expect(utils_1.toBoolean('On')).toBe(true);
        expect(utils_1.toBoolean('oN')).toBe(true);
        expect(utils_1.toBoolean(' on ')).toBe(true);
        expect(utils_1.toBoolean(' On ')).toBe(true);
        expect(utils_1.toBoolean(' oN ')).toBe(false); // error

the compilation is somehow removing blank lines. Does that sound familiar to you?

PS: If I remove all blank lines from my original code then jest reports the error line number correctly

@thiagoh I’m curious…are you doing coverage analysis. I ask because I was having issues with lines not matching up while debugging. I would add debugger statements. It would jump into the debugger, but it would mark the wrong line. The farther into the file the debugger statement was, the more off it was, generally speaking. I noticed that removing blank lines had an effect, but it wasn’t just blank lines that were causing this. But then I thought to try it with --coverage false and everything worked perfectly.

@kulshekhar I can give you a reproducible test case for this, but it won’t be minimalistic if you want to try and chase it down. I can also open a separate issue if you want, to avoid confusion. Just let me know.

I was definitely loading it manually! Fixed!

@kulshekhar Sorry, I could have done that at the time, but I’ve now worked through whatever issues I had so I don’t think I could reproduce this now. Sorry.

@thiagoh can you try skipping babel?

be sure to clear the cache before that

sorry @kulshekhar I also can’t reproduce the error right now… some library might have been updated since yesterday… I have a private repo at work where this error happens… I will try to understand what’s going on there and get back to you here… thanks