[Feature]: support experimental best-effort source-map remapping in module errors

[h-a-n-a]

What problem does this feature solve?

In the current implementation of rspack, module build error and module parse error would be mapped based on the output of loader, which leads its corresponding error span not being able to mark the user input.

What does the proposed API of configuration look like?

This will work better, in the best case scenario, if options.devtool set to module related options (for example: cheap-module-source-map) and will be remapped along with errors lazily for better performance.

This does not expose any JS APIs, however it could be enabled with experiments options, the exact option name remains to be determined. This is built-on the contract that source-map must be correct, otherwise the remapped source or span message might be incorrect. So this feature should be opt-in in compiler-wise or module rule wise.

[h-a-n-a]

Compiler-wise

Toggle made to the whole compiler, turning in on means this will apply to every module during each compilation.

Pro:

1. Easy to use

Con:

1. The correctness of sourcemap should be guaranteed, otherwise the result will be not correct.

Module rule wise

Support toggling in module rule wise, this can only opt-in only a certain pieces of modules in the remapping, for example: user code.

Pro:

1. Flexible enough to turn off for certain modules.
2. Potential benchmark gains, as modules in node_modules often does necessarily to be mapped.

Con:

1. Place to put this option remains to be determined.

[hardfist]

I think this should be a opt-in feature(other than opt-out) considering we have no way to guarantee the source-map correctness and it's the same behavior like --enable-source-maps.
From my personal experience, incorrect node_modules source-map is very normal(people may forget to upload source file to npm but keeps source file in source-map)
maybe we can implement it as a user land plugin first and see whether it works for most scenarios

[h-a-n-a]

I think this should be a opt-in feature(other than opt-out) considering we have no way to guarantee the source-map correctness and it's the same behavior like --enable-source-maps. maybe we can implement it as a userland plugin first and see whether it works for most scenarios

I agree with you, and I would suggestion this feature should be opt-in compiler-wise or module rule wise. But feel free to propose with a better solution if you have any ;-).

Edit: Plugin looks good to me too, but it does not solve the problem of placing it on compiler-wise or module rule wise.

From my personal experience, incorrect node_modules source-map is very normal(people may forget to upload source file to npm but keeps source file in source-map)

In this case, if there's no either sourceContent or file available in the source-map, then rspack should bail-out.

[hardfist]

Edit: Plugin looks good to me too, but it does not solve the problem of compiler-wise or module rule wise.

It seems you can control this in plugin options? since you got whole sourcemap and error location info in stats, so you can do reverse mapping for any module?

[h-a-n-a]

Edit: Plugin looks good to me too, but it does not solve the problem of compiler-wise or module rule wise.

It seems you can control this in plugin options? since you got whole sourcemap and error location info in stats, so you can do reverse mapping for any module?

Sure we have the capability to handle this, the design part should be deliberately considered for the best user experience.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. If this issue is still affecting you, please leave any comment (for example, "bump"). We are sorry that we haven't been able to prioritize it yet. If you have any new additional information, please include it with your comment!

[h-a-n-a]

bump

[stale]

This issue has been automatically marked as stale because it has not had recent activity. If this issue is still affecting you, please leave any comment (for example, "bump"). We are sorry that we haven't been able to prioritize it yet. If you have any new additional information, please include it with your comment!