Allow moduleNameMapper config override

[sebald]

This patch will allow path mapping to be fully supported, by allowing moduleNameMapper to be configured.

Issue

Currently, you can add paths to your tsconfig and the app will run fine. But jest / ts-jest does not use the configuration from your tsconfig. Configuring the moduleNameMapper will solve this. Sadly, the property is not "supported" and tests can not be run if the configuration is set.

Example usage:

Changing the following files will allow you to import modules from the src folder, by prefixing the import path with a tilde. E.g. a component living in src/components/Button can always be imported via ~/components/Button. No ../../../ anymore!

tsconfig.json

{ "compilerOptions": { ... + "baseUrl": ".", + "paths": { + "~/*": ["src/*"] + } }, 

package.json

{ ... "jest": { ... + "moduleNameMapper": { + "^~/(.*)$": "<rootDir>/src/$1" + } }, }

Changes:

1. Add baseUrl so tsconfig-paths-webpack-plugin will not warn that it is missing (Fixed problem with tsconfig.json baseUrl and paths #223)
2. Allow overriding moduleNameMapper (Support for TypeScripts 'paths' option #203)

Allow overriding the moduleNameMapper configuration is the pragmatic approach. If you're using absolute paths + react-native you would have to re-add the mapping.

[farzadmf]

Any news on this? Any plan to merge this PR to have moduleNameMapper support?

[DorianGrey]

• This should be listed in the corresponding README to be adjustable. Just recognized that the original section on CRA (https://github.com/facebook/create-react-app/blob/master/packages/react-scripts/template/README.md#configuration) is absent here... However, this field (and potentially the section) should be listed there, including the example usage and a note on how this relates to entries in the tsconfig.json.
• I'm still thinking about the default value used on this field, '^react-native$': 'react-native-web'. It should either be noted that it has to be provided manually in case of overriding this key, or that entry should be merged automatically. Suppose the first way might be preferable.

[DorianGrey]

I'm very sorry for the late response, I was quite busy lately and also attempted to figure out why the travis build began to fail shortly after it was fixed for the master branch ...

Comments are attached on the review.

[sebald]

@DorianGrey No problem, I'll integrate the suggested changes next week 🙂

[sebald]

@DorianGrey added the section to the readme as suggested 🙂

[DorianGrey]

LGTM, thanks!

(Note: I'll ignore the failing CI for the moment - that kitchensink case is extremely unstable, still working on a fix for that).

[adambowles]

Nice! When will this be released to npm?

[DorianGrey]

I'm still waiting for a reaction on #314 to figure out if pinning the @types/node version can be reverted or has to be retained. Would be favorable to figure this out before an additional release.