Work around moduleNameMapper problem

• Type: Task
• Status: Closed
• Priority: Minor
• Resolution: Completed
• Affects Version/s: None
• Fix Version/s: None
• Component/s: Frontend Infrastructure
• Labels: None
• Epic/Theme:
  • FI_Additional_Work
• Sprint: S03E21 - Vienna, S03E22 - Tokyo, S03E23 - Olinda, S03E24 - Wuhan
• Git Pull Request: https://github.com/marcosapmf/liferay-portal/pull/7

marcos.martins: just creating this LPS so I can send you a PR with the workaround for the moduleNameMapper issue you reported here:

https://liferay.slack.com/archives/CNBG06JS3/p1585226190005800

As we noted there, the import path starts with: "/js/components/..."

The autogenerated moduleNameMapper has this config in it:

https://gist.github.com/wincent/6cc3ece6cd2ded0f62aa79942eabd791#file-temp_jest-config-json-in-dynamic-data-mapping-form-web-json-L48

So it basically appends "/js/components/..." etc to the module path which itself ends with "/js", causing a bad path to be yielded with a double "/js/js/" in it.

Root cause is we have inconsistent module structure where some projects put their "main" entry point in "resources/js/" and others directly under "resources/". I'll try to provide a robust solution in liferay-npm-scripts, but for now the immediate workaround is to overwrite moduleNameMapper locally.

I think we can discard the alternate fix of making all modules have the exact same structure — that would be too much churn (and risk) for small payoff.

Will send you PR with workaround presently.