Open jeffrson opened 3 years ago
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.
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.
This should still be open, right @log101?
@jssuttles I guess so, no PR's referencing this issue has been merged.
Bug report
What is the current behavior? Webpack in some cases reports errors according to .js files instead of originating .ts files. For the repro below the error is
Line number of error is 8 instead of 13 as in startup.ts - line 8 is the corresponding number from the .js file if package would be compiled with typescript.
If there would be a typescript error, the correct line of the error will be output.
If the current behavior is a bug, please provide the steps to reproduce.
https://github.com/jeffrson/webpack-ts-line-numbers.git
call
yarn
thenyarn webpack
finally checkyarn tsc
for comparing startup.jsWhat is the expected behavior?
should report line 13 and correct columns for file startup.ts
Other relevant information: webpack version: 5.5.1 Node.js version: 14.15.1 Operating System: Windows 10 Additional tools: