I think it is expected, because resolving based on outputed file from loader, but yes, we can improve this, something like:

ERROR in ./startup.ts 8:11-31 (original 13:11-31)

In this case it seems to be simple, but in a real project it's quite confusing if you look at the reported line and cannot find the cause.

In theory the transpiled .js could be reported (instead of .ts), but since this does not exist to have a look at for reference this is not quite helpful as well.

Yep, it will be great to improve this

Assign it to me so that I can try to solve this.

But which loader are you using to process typescript @jeffrson

Just ts-loader

ts-loader is a custom package created by TypeStrong. Its not a webpack owned loader in Webpack-contrib Github account.
I think I should go to ts-loader repo in order to fix this.

This issue had no activity for at least three months.

It's subject to automatic issue closing if there is no activity in the next 15 days.

Issue was closed because of inactivity.

If you think this is still a valid issue, please file a new issue with additional information.

Still valid, we can get real position from source map, if they present

Is there a workaround ? Or do we need to wait for this to be completed?

ts-loader makes wrong source map line/column numbers.

In case anyone comes across this issue and just wants a temporary workaround, I've added what works for me here

UPDATE A more user-friendly and perhaps more permanent solution here

Since the other issue is closed does this mean there won't be any fix?
I have the same config as in the examples but the lines are still wrong - however I use Vue if that matters

I had a chance to work a bit on this issue. I'm able to get the original lines and locations of the error using the source map as @alexander-akait advised. I used source-map library for the conversion, but I wonder where is the right place to do it. For example it could be done here for the ModuleNotFoundError:

I could update the dependency location (loc property), but it seems like this logic should be implemented for all errors.
So my idea is to do this conversion using the failedModule hook. Basically it'll check if the source map is available, if yes it'll do the conversion. Does this make sense?

I think we should do it after loader processing

I've been working on this problem since last week trying to find possible solutions. I'm still familiarizing myself with the codebase so I'm definitely open for feedback. Just to ensure I'm on the same page, I'd like to briefly describe the issue:
The problem is the misalignment of dependency locations. Misalignment occurs when a parent module is processed by loaders, changing line numbers. So when deps generate errors, the line numbers does not align with the original file, creating confusion. I have two potential solutions:

1. As @alexander-akait suggested, converting the line numbers after loader processing. This could be implemented in the NormalModules's build function. handleParseResult function inside is called after module is built. Before sorting the deps at line 1109 we could add a mapper that'd convert the line numbers according to the original file using the source map. Such as:

// Check if source map is present
if (this.originalSource().map()) {
    this.dependencies.map(dep => convertLineNumbers(dep))
}

2. Update the deps before ModuleNotFound error is thrown. But this would only fix the problem for one type of error. Before instantiating the ModuleNotFoundError class at line 2094, we could:

dependencies.map(dep => convertLineNumbers(dep))

The first solution looks good, but let's it do only for errored modules

In order to confine the fix to errored modules only as @alexander-akait suggested, I deferred updating the error location to the module factorization.