When using Jasmine with webpack in a hybrid (AngularJS + Angular) App, we are unable to decipher the line numbers

[nithusha21]

We use Jasmine for frontend testing, in our AngularJS + Angular hybrid app at Oppia https://github.com/oppia/oppia.

We use webpack, and have configured Karma to use a combined spec file, using resolve.context.

The error logs if the tests fail, give the line numbers in the combined-tests spec file which is pretty useless to debug as we only get the name of the failing suite. Are we configuring something wrong? Or is there some way to use a sourcemap style idea to map the line numbers to the original file line numbers?

Expected Behavior

I would like to get the actual line numbers of the failing assertions, and not the line numbers from the combined spec file.

Current Behavior

Currently we get the line numbers from the combined spec files, which doesn't help with debugging.

Context

The error logs if the tests fail, give the line numbers in the combined-tests spec file which is pretty useless to debug as we only get the name of the failing suite. Are we configuring something wrong? Or is there some way to use a sourcemap style idea to map the line numbers to the original file line numbers?

Your Environment

Here is the configuration file: https://github.com/oppia/oppia/blob/develop/core/tests/karma.conf.ts
Here is the code that combines the spec files into a single test file: https://github.com/oppia/oppia/blob/develop/core/templates/combined-tests.spec.ts#L87

• Version used:
• Environment name and version: Chrome headless, node 12.16, karma-jasmine 4.0.1
• Operating System and version: Any
• Link to your project: https://github.com/oppia/oppia

[sgravrock]

You're not missing anything. Jasmine doesn't currently support source maps except in environments/configurations where we get it "for free". See this comment for the current state of affairs. But to sum up briefly, this is hard because:

• The existing libraries that we can use to process source maps all depend on promises, which is a problem for IE.
• Building/packaging those libraries in a way that doesn't introduce polyfills is hard.
• It's a lot of work, and so far nobody with the right skills wants source map support badly enough to do the work.

I think this is a duplicate of #491, so I'm going to close it in favor of that issue.