You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Feb 18, 2024. It is now read-only.
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.
The text was updated successfully, but these errors were encountered:
davidje13
added a commit
to davidje13/neutrino
that referenced
this issue
Dec 4, 2020
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.The text was updated successfully, but these errors were encountered: