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
bundle-buddy works of off the following concept:
For every source file exposed by the source map
main.js
foo.js
bat.js
zap.js
We determine the size of the file by reading in the sourcemapped content, this gives us the ability to identify how large each file is. There is nothing new being done here as this is what source-map-explorer and other tools have been doing for a while.
Where bundle buddy is different is that where other tools use folder structure to show file relationships, we go a step further and look into the source to dependency graph to understand how the files are coming into the bundle (this information is exposed by webpack/rollup/rome already).
So in our example let's assume we have
main.js
import 'foo.js'
import 'bat.js'
and foo.js has
import 'zap.js'
We can then create a graph of the dependencies for each file.
main.js -> foo.js -> zap.js
main.js -> bat.js
By combining the graph of files + each files source weight we can being to expose some very dynamic information such as the transitive dependency weight of a given import.
Problem:
A project has the following
import * as Sentry from "@sentry/browser";
Looking into node_modules, the @sentry module ships with the following code:
dist/index.js
dist/index.js.map
.
.
When webpack is compiling this project webpack ONLY knows about the .js sources exposed through the module, however the sourcemaps that are included with the shipped js code from the @sentry module contain sourcemapping references back to the original ts/development sources that webpack does not know about at all.
This means when we get to the phase of joining the sourcemap information with the graph/dependency information from webpack that we hitting a problem. the sourcemaps know about sources that webpack does not know about this we are unable to determine to map N dist files to Y source map files.
As an example
dist/index.js is actually made up of src/index.ts src/index2.ts src/index3.ts
This is a tricky situation for sure, I can think of several paths forward:
Pull in the source of @sentry and consume the ts directly in the project so that webpack has perfect vision into the files and dependency graphs
teach webpack/compilers to have a concept of a prebuilt composite file based on the sourcemap information
Overall this is an ugly situation and I am curious if anyone has any ideas.
The text was updated successfully, but these errors were encountered:
At least there is an (expensive) way to get this information in a plugin.
This snippet allow to get all source map names associated with a module.
module.originalSource()?.map().sources
These are absolute paths and they still get RequestShortener.shorten and sometimes hash is appended to avoid conflicts. Not so pretty.
A few changes in webpack may allows a cheap way of receiving this information and we could add it to the stats info for each module. sourceMapSources: [...]
You could also parse the AST of the output bundle to get the ranges of modules and their IDs.
This could be a bit error-prone when webpack changes it's output AST format (e. g. from webpack 4 to 5), but it would also allow to assign code that is unmapped in source map (e. g. generated code from webpack e. g. from imports).
Background:
bundle-buddy works of off the following concept:
For every source file exposed by the source map
We determine the size of the file by reading in the sourcemapped content, this gives us the ability to identify how large each file is. There is nothing new being done here as this is what source-map-explorer and other tools have been doing for a while.
Where bundle buddy is different is that where other tools use folder structure to show file relationships, we go a step further and look into the source to dependency graph to understand how the files are coming into the bundle (this information is exposed by webpack/rollup/rome already).
So in our example let's assume we have
main.js
and foo.js has
We can then create a graph of the dependencies for each file.
By combining the graph of files + each files source weight we can being to expose some very dynamic information such as the transitive dependency weight of a given import.
Problem:
A project has the following
Looking into node_modules, the @sentry module ships with the following code:
When webpack is compiling this project webpack ONLY knows about the
.js
sources exposed through the module, however the sourcemaps that are included with the shipped js code from the @sentry module contain sourcemapping references back to the originalts/development
sources that webpack does not know about at all.This means when we get to the phase of joining the sourcemap information with the graph/dependency information from webpack that we hitting a problem. the sourcemaps know about sources that webpack does not know about this we are unable to determine to map N dist files to Y source map files.
As an example
dist/index.js
is actually made up ofsrc/index.ts
src/index2.ts
src/index3.ts
This is a tricky situation for sure, I can think of several paths forward:
prebuilt
composite file based on the sourcemap informationOverall this is an ugly situation and I am curious if anyone has any ideas.
The text was updated successfully, but these errors were encountered: