danvk / source-map-explorer

Analyze and debug space usage through source maps
Apache License 2.0
3.82k stars 100 forks source link

Allow to use custom bundles #156

Open zamotany opened 4 years ago

zamotany commented 4 years ago

Is your feature request related to a problem? Please describe. In some environments like React Native there is a possibility of using different type of bundles, which does not consist only of plan JavaScript. One of the example is an Indexed RAM bundle in React Native which is a mix of binary metadata and the JavaScript source code (more info here) and File RAM bundle, which spreads modules into separate files.

It would be awesome if we could get an option to analyse those bundles, more specifically have an option in inject custom logic that allows to analyse them.

Describe the solution you'd like Essentially the solution is to allow to customise parts of the source-map-explorer pipeline. For example RAM bundles are so different compared to regular plain JS bundles, that almost the whole code for iterating over mappings and computing sizes has to be altered and only the visualisation part is usable.

Describe alternatives you've considered I was thinking about 2 options that would work:

  1. Allow to customise computeFileSizes (provide custom one) in the Node API or in other way eg:

    explore('dummy.js', { // for RAM bundles we cannot use the built-in logic for reading/loading code/maps
    output: { format: 'html' },
    computeFileSizes: (
    sourceMapData: SourceMapData,
    options: ExploreOptions,
    coverageRanges?: CoverageRange[][]
    ): FileSizes => {
    // custom logic here
    }
    })
  2. Hide bundle specific operations like loading source code, loading source map, getting mappings, computing file sizes behind an abstraction and implement this abstraction for plain/regular JS bundles for example (rough draft):

    
    type SourceAndMapBuffers = { code: Buffer, map?: Buffer };

interface BundleAnalyzer { load(fileTokens: Array<string | { code: string, map?: string }>, options: LoadOptions): SourceAndMapBuffers[]; computeSizes(sourceAndMapBuffers: SourceAndMapBuffers[], options: ComputeSizeOptions): FileSizes[]; }

class MyBundleAnalyzer implements BundleAnalyzer { // implement load and computeSizes here }

explore(new MyBundleAnalyzer()); // passing currently available options would make source-map-explorer use built-in PlainJavaScriptBundleAnalyzer



**Additional context**
I'm open to other suggestions/ideas and once we get some agreement which path we should take, we will create a PR to add this support.

cc: @danvk @nikolay-borzov 
danvk commented 4 years ago

Related to #135. I do think there would be value in separating out the "source-map" and "explore" parts of this tool.

zamotany commented 4 years ago

@danvk How about exposing function(s) that takes info about modules and it's file sizes (eg FileSizes type) which would generate the reports? That way we could implement computation ourselves but still use the visualization related logic. Is that what you had in mind?