A puzzling situation

[samccone]

Background:

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:

1. 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
2. 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.

[sokra]

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).