-
-
Notifications
You must be signed in to change notification settings - Fork 359
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix: correctly report error numbers in stack traces #619
Comments
@stevenvachon if I follow, line numbers are still incorrect with @kpdecker perhaps you could help debug a bit? I haven't played too much with this feature -- hopefully there hasn't been a regression. @stevenvachon would definitely love to get this working for you; would also any help you can provide debugging, if you have any spare cycles. |
@bcoe you followed correctly. I can maybe try to help debug. |
@stevenvachon would definitely appreciate help digging into this; sounds like potentially a regression with produce-source-map. |
I faced a similar issue with I think I've gotten it working after adding both the To me it feels like it has something to do with instrumenter caching - if I recall correctly, there was also some weirdness along the lines of:
I may not have remembered the above steps/results entirely accurately, but it definitely felt anomalous so that could be a potential lead. |
@sneakertack a similar class of bug has been reported by @isaacs' related to stack-traces getting out of alignment when using arrow-functions ... it might be worth diving a bit deeper into the source-maps being generated by Istanbul's instrumenter ... feels like something is out of whack. |
I'm having similar line number issues with
// A "test" command in `@my-company/ts-build-tools`
// which ts-based packages use to build themselves.
// http://web.archive.org/web/20170101073300/http://rundef.com:80/typescript-code-coverage-istanbul-nyc
// http://rundef.com/typescript-code-coverage-istanbul-nyc
const cliCommand = '${TOOLS_NODE_MODULES_DIR}/.bin/nyc';
const cliArgs = ([
'--require', '${TOOLS_DIR}/src/mocha-ts-node-register.js',
'--extension=.ts',
'--extension=.tsx',
'--extension=.js',
'--extension=.jsx',
'--include=src/**',
'--include=test/**',
'--exclude=**/*.d.ts',
'--all',
]).concat(
(!shouldFailOnCoverageCheck ? [] : [
'--check-coverage',
'--lines', String(coverageCheckLinesThreshold),
])
).concat([
'--reporter=lcov',
'--reporter=text-summary',
'--reporter=text',
'${TOOLS_NODE_MODULES_DIR}/.bin/mocha',
'-t', String(testsTimeout),
'${PROJECT_DIR}/test/test.ts',
]);
spawn(cliCommand, cliArgs, {}, onTestDone); // @my-company/ts-build-tools/src/mocha-ts-node-register.js
const expandPaths = require('./paths').expandPaths;
require('ts-node').register({
project: expandPaths('${PROJECT_DIR}/test/tsconfig.json'),
});
{
"compilerOptions": {
"target": "ES5",
"lib": [ "ES5", "ES6", "ES2015" ],
"module": "commonjs",
"outDir": "./lib",
"sourceMap": true,
"listFiles": false,
"listEmittedFiles": false,
"pretty": true,
"traceResolution": false,
"declaration": true,
"alwaysStrict": true,
"noImplicitAny": true,
"noImplicitReturns": true,
"noImplicitThis": true,
"strictNullChecks": true,
"downlevelIteration": true,
"typeRoots": [
"./node_modules/@my-company/ts-build-tools/node_modules/@types",
"./node_modules/@types"
]
},
"include": [
"./src/**/*.ts",
"./typings/**/*.d.ts",
"./node_modules/@my-company/ts-build-tools/shared/typings/**/*.d.ts"
],
"exclude": [
"./node_modules"
]
}
{
"extends": "../tsconfig.json",
"compilerOptions": {
"outDir": "../lib/test"
},
"include": [
"../test/**/*.ts",
"../typings/**/*.d.ts",
"../node_modules/@my-company/ts-build-tools/shared/typings/**/*.d.ts"
],
"exclude": [
"../node_modules"
]
} Example assert error in a test (obviously, the error is not at line 3 and character 11736):
Also these look related: |
It would be nice to, once and for all, correctly report line numbers in stack traces in as many common nyc configurations as possible. A good start would be to add some unit tests to istanbul-lib-instrument. to test the simple cases. |
I'm having a similar issue with nyc and ava. Ref: avajs/ava#1604 |
We are experiencing similar problem in https://github.com/strongloop/loopback-next:
(cc @raymondfeng) |
Yeah this is 🍌 . Between running @bcoe given that I'm not running anything fancy, just straight up |
I have the same problem. Is there any solution? |
Having that problem too. Using nyc + mocha + ts-node. Source maps activated everywhere. Edit: "scripts": {
...
"test": "cross-env TS_NODE_FILES=true mocha --opts mocha.opts",
"posttest": "cross-env TS_NODE_FILES=true nyc mocha --opts mocha.opts",
...
}, if tests fails, posttest won't run and stacktrace without nyc will be output. |
I believe we are having the same problem as @bajtos (Hi, we use Loopback 👋 !) - we are not using ts-node. We have TSC compile sourceMaps (as external .map files, not inline) and we have mocha When we run mocha itself, everything works great. When we run |
Is there any update on the matter? using @ianldgs workaround feels wrong as the test run twice and as he states it is just a workaround. I believe this is a breaking issue on both the JavaScript and the TypeScript environment as being able to read meaningful stacktraces in unit and integration tests is a core reason for writing tests in the first place. |
as requested in istanbuljs/nyc#619
@JaKXz I think this is the same issue that I was about to report. This example uses only mocha and nyc. https://github.com/alex028502/nyc-line-number-issue I have put |
@alex028502, I confirm your small repro works exactly as described and fails as you describe. Nice work. |
Any update on this? We're using es6 code only and |
This issue is blocked by evanw/node-source-map-support#239. The issue is that nyc source-maps are inline but node-source-map-support does not look at inline source-maps by default. |
I wonder why the |
The solution I identified was to manually add the following lines to my test suite at the top of
Then running
|
In newer versions of Node.js, you could also try running with |
Can confirm that |
Also replaced 'souce-map-support' with the V8's builtin feature.
How can we use this command? I tried this without success
|
This worked for me |
So after 7 years.... The problem remains....this is sadly unacceptable for a tool like this... |
I've been having this issue periodically across my projects, and today I finally fixed it for one of the projects. I run nyc, mocha, and ts-node together on NodeJS Hope that helps someone. 😄 |
When I take my mocha code out of nyc, the line numbers are correct, so I know that nyc is to blame.
stevenvachon/incomplete-url@9c6eb47
produces: https://travis-ci.org/stevenvachon/incomplete-url/jobs/248590761
I get the same result when adding source-map-support:
nyc --source-map --produce-source-map mocha test --require=source-map-support/register
The text was updated successfully, but these errors were encountered: