You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, source mapped stacktraces reference line numbers from the optimized dependency output file in the cache, rather than from the source files of the dependency optimization step, even though esbuild includes sourcemaps in the cache.
Suggested solution
The load hooks of the vite:optimize-deps and vite:optimize-deps-build plugins could load both the code and map from the cache, returning both {code:, map:} instead of just the code:
rollup-plugin-sourcemaps provides a good example of loading the sourcemap from the filesystem (albeit using the deprecated source-map-resolve library) but something simpler could be done because the cache output of the esbuild optimize step probably has a very consistent sourcemap file location).
Alternative
The rollup-plugin-sourcemaps plugin does not work in this situation because it depends on a load hook, but the optimize-deps plugins depend on their own load hook.
I faced such an issue too!
When the dependency is auto-including in the optimization list - I can't access its sourcemaps in DEVELOPMENT. However, once I manually exclude them using the optimizeDeps.exclude - they appear in the dev tools!
Description
Currently, source mapped stacktraces reference line numbers from the optimized dependency output file in the cache, rather than from the source files of the dependency optimization step, even though esbuild includes sourcemaps in the cache.
Suggested solution
The load hooks of the
vite:optimize-deps
andvite:optimize-deps-build
plugins could load both thecode
andmap
from the cache, returning both{code:, map:}
instead of just the code:https://github.com/vitejs/vite/blob/main/packages/vite/src/node/plugins/optimizedDeps.ts#L69
https://github.com/vitejs/vite/blob/main/packages/vite/src/node/plugins/optimizedDeps.ts#L142
rollup-plugin-sourcemaps provides a good example of loading the sourcemap from the filesystem (albeit using the deprecated source-map-resolve library) but something simpler could be done because the cache output of the esbuild optimize step probably has a very consistent sourcemap file location).
Alternative
The rollup-plugin-sourcemaps plugin does not work in this situation because it depends on a load hook, but the optimize-deps plugins depend on their own load hook.
Additional context
No response
Validations
The text was updated successfully, but these errors were encountered: