When custom moduleNameMapper config is provided, it ends up at the bottom of the list, below automatic configuration for static file types (stylesheets / images). This causes problems when mocking out more complex interpretations of these file types (e.g. SVGR creates additional exports for SVG files).
The given config is ignored, because the built-in SVG rule takes priority (using file-mock).
This could be fixed by putting user-specified moduleNameMapper entries at the top of the resulting config, rather than the bottom. I think it is reasonable for anything the user specifies to override the defaults.
When custom
moduleNameMapper
config is provided, it ends up at the bottom of the list, below automatic configuration for static file types (stylesheets / images). This causes problems when mocking out more complex interpretations of these file types (e.g. SVGR creates additional exports for SVG files).For example:
Where svgr.js contains:
The given config is ignored, because the built-in SVG rule takes priority (using
file-mock
).This could be fixed by putting user-specified
moduleNameMapper
entries at the top of the resulting config, rather than the bottom. I think it is reasonable for anything the user specifies to override the defaults.