Closed jasonterando closed 1 year ago
@jasonterando, Thanks for the sample repo, I was able to reproduce your issue with it. However, once I changed the "sourceMaps" to true, everything worked fine. See the video below.
https://github.com/jest-community/vscode-jest/assets/891093/b206d2b8-48fd-441d-8c95-5b8836d5a6ef
Perhaps there is something else going on in your original project? Breakpoint issues, like the one you described, are usually sourcemap-related, the sample repo is a clear example.
(facepalm) - it's been a long morning lol. Yeah, set that to true and things seem to be better. Meanwhile, in my "real" project, I had to back out a bunch of other stuff I was trying to get it to work (mostly stuff around modules).
Thank you for responding so quickly and over a weekend!
Here's what seems to be good for me at the moment, in case it helps someone else:
/** @type {import('ts-jest').JestConfigWithTsJest} */
// jest.config.js
const { pathsToModuleNameMapper } = require('ts-jest');
// In the following statement, replace `./tsconfig` with the path to your `tsconfig` file
// which contains the path mapping (ie the `compilerOptions.paths` option):
const { compilerOptions } = require('./tsconfig.json');
module.exports = {
preset: 'ts-jest',
testEnvironment: 'node',
verbose: true,
setupFilesAfterEnv: [
"./tests/setup.ts"
],
collectCoverageFrom: [
"src/*.ts",
"src/**/*.ts"
],
transformIgnorePatterns: [
"node_modules/module-i-have-to-use",
"/dist/.+\\.js"
],
testMatch: [
"**/*.test.ts"
],
roots: [
"<rootDir>/tests"
],
moduleNameMapper: pathsToModuleNameMapper(compilerOptions.paths /*, { prefix: '<rootDir>/' } */)
};
import 'reflect-metadata'
{
// Use IntelliSense to learn about possible attributes.
// Hover to view descriptions of existing attributes.
// For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
"version": "0.2.0",
"configurations": [
{
"type": "node",
"name": "vscode-jest-tests.v2",
"request": "launch",
"args": [
"--runInBand",
"--watchAll=false",
"--testNamePattern",
"${jest.testNamePattern}",
"--runTestsByPath",
"${jest.testFile}"
],
"env": {
"NODE_OPTIONS": "--experimental-vm-modules"
},
"cwd": "${workspaceFolder}",
"sourceMaps": true,
"stopOnEntry": true,
"console": "integratedTerminal",
"internalConsoleOptions": "neverOpen",
"program": "${workspaceFolder}/node_modules/.bin/jest",
"windows": {
"program": "${workspaceFolder}/node_modules/jest/bin/jest"
}
}
]
}
This looks like an issue numerous people have bumped up against. I've read about attempts to address this by setting disableOptimisticBPs to true and/or sourceMaps to false, but disableOptimisticBPs isn't available anymore and sourceMaps didn't do anything for me. I've messed for hours with settings in Jest and ts-jest based upon old posts but to no avail. Thus, I'm posting here to hopefully get some more updated guidance, and have created a minimal demo project to demonstrate what I'm running into.
Environment
vscode-jest version
:v5.2.3node -v
:18.17.1npm -v
oryarn --version
: 10.1.0npm ls jest
ornpm ls react-scripts
: 29.7.0ts-jest
: version 29.1.1Prerequisite
npx jest
Steps to Reproduce
Repository at https://github.com/jasonterando/demo-vscode-jest-vs-ts-jest. This is as minimal of a project as I can think of that demonstrates the issue. The MyClass.bad method throws an unhandled Error. When running from the command, the correct line is displayed. When running from vscode-jest, the incorrect line is displayed. The same issue manifests when setting a breakpoint at the location.
npm install
npx jest
to run unit tests, test fails with the correct line displayedExpected Behavior
Upon breakpoints or uncaught exceptions, the correct line will be displayed/highlighted.
Actual Behavior
Upon breakpoints or uncaught exceptions, the incorrect line will be displayed/highlighted
Screenshots
Running
npx jest
from the command line shows the correct location of the uncaught error:Debugging unit tests in vscode-jest highlights the incorrect line, but notice that the correct line is referred to in the output from Jest
Debug breakpoint set at line 9...
...is offset by two lines during debugging