Fix a compilation error that occurs when the "paths" option is not set but "baseUrl" is

[mprahl]

Fixes #9671

[googlebot]

Thanks for your pull request. It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

📝 Please visit https://cla.developers.google.com/ to sign.

Once you've signed, please reply here (e.g. I signed it!) and we'll verify. Thanks.

---

• If you've already signed a CLA, it's possible we don't have your GitHub username or you're using a different email address on your commit. Check your existing CLA data and verify that your email is set on your git commits.
• If your company signed a CLA, they designated a Point of Contact who decides which employees are authorized to participate. You may need to contact the Point of Contact for your company and ask to be added to the group of authorized contributors. If you don't know who your Point of Contact is, direct the project maintainer to go/cla#troubleshoot. The email used to register you as an authorized contributor must be the email used for the Git commit.
• In order to pass this check, please resolve this problem and have the pull request author add another comment and the bot will run again. If the bot doesn't comment, it means it doesn't think anything has changed.

[mprahl]

I signed it!

[googlebot]

CLAs look good, thanks!

[clydin]

Thank you for the contribution. However, while this may fix the problem observed within the referenced issue, this will break module resolution in the general case. The ts.resolveModuleName method is unfortunately too course-grained to fully support module resolution in all cases.

[mprahl]

@clydin what cases would cause this to break? This works on a new app generated from angular-cli and the app that wouldn't compile with v1.7.0.

[clydin]

For a package, ts.resolveModuleName will resolve to the typings/types field of the package.json. While appropriate for transpiling typescript, this is not the case for bundling the actual code for the package. The location of the actual code can potentially be found at multiple locations depending on the configuration (e.g., fields such as main, browser, module, or es2015). As the type definition file can be located at an arbitrary location within the package; there's no clean method to determine the appropriate source code file from only the path of the type definition file returned. Factor in deep imports, as well as the no-typings fallback case of using a root index.ts/index.js, and ts.resolveModuleName is not useable for general resolution. If the intrinsics behind the method were publicly available, it would potentially possible.
Longer-term, the method's use will most likely be removed.

[angular-automatic-lock-bot]

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{This action has been performed automatically by a bot.}