[kwy404]

Summary

Projects that set serializer.processModuleFilter (for example to build a split bundle without the polyfills and modules already shipped in a base bundle) and use an inline source map (metro build --source-map or runBuild with sourceMap: true and no sourceMapUrl, or a dev server request with ?inlineSourceMap=true) get a map in which every module after a filtered one is shifted down by the filtered module's lines, so stack traces and debugger locations point to the wrong file and line.

baseJSBundle drops filtered modules from the bundle code (processModules(..., {filter: options.processModuleFilter})), but getAppendScripts built the inline map with processModuleFilter: () => true, so the filtered modules still took up lines in it. The external .map already uses config.serializer.processModuleFilter in Server, so only the inline map disagreed with the code it describes.

This passes processModuleFilter from the serializer options to getAppendScripts and uses it for the inline map, the same way as for the external map.

Changelog: [Fix] Apply serializer.processModuleFilter to inline source maps, so their mappings match the filtered bundle

Test plan

Added a test to baseJSBundle-test.js that filters out the polyfill and checks the sections of the inline source map. Before this change foo and bar were mapped to lines 1 and 2, although the filtered bundle starts with them on lines 0 and 1, so the test failed. With the change it passes.

yarn jest packages/metro/src/DeltaBundler/Serializers packages/metro/src/lib
Test Suites: 27 passed, 27 total
Tests:       226 passed, 226 total

eslint and prettier --check pass on the changed files.

[robhogan]

Thanks! This looks right. Users of the private getAppendScripts will need to ensure they start passing the extra option, but eg Expo can handle that when we bump pinned Metro.