source-map-explorer icon indicating copy to clipboard operation
source-map-explorer copied to clipboard

Allow to use custom bundles

Open zamotany opened this issue 5 years ago • 2 comments

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

zamotany avatar Jan 15 '20 12:01 zamotany

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

danvk avatar Jan 15 '20 20:01 danvk

@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?

zamotany avatar Jan 15 '20 20:01 zamotany