Fix relative paths with bundleDependencies=false

[amakhrov]

When bundleDependencies is turned off, webpack is configured to bundle all modules imported via relative path.
It works well for import paths like './some/file' but fails for imports traversing the dir structure up, like '../some/file'.

In most cases it would still work well, because of the additional fallback (which checks whether node can resolve this module at all). However, in rare cases this fallback fails (see https://github.com/angular/universal/issues/1792)

Closes: #18493

[amakhrov]

@googlebot I signed it!

[googlebot]

CLAs look good, thanks!

ℹ️ Googlers: Go here for more info.

[alan-agius4]

The commit message is not valid.

The commit message header should start with fix(@angular-devkit/build-angular):

See: https://github.com/angular/angular-cli/blob/master/CONTRIBUTING.md

[alan-agius4]

Thanks LGTM

[amakhrov]

Thanks for the super quick feedback @alan-agius4 - quite impressive!

[amakhrov]

@alan-agius4 I have a followup question though.
While the PR seems to fix the specific issue I was facing, I'm wondering if there are more cases that could fail like that.

As I mentioned, despite the incomplete original check for partial path, the builds tend to work well.
The reason is that if this check returns false, the code below has an extra check - tries to resolve the path via require.resolve. But this resolve call is performed in the context of server.ts file, not in the context of the compiled module.
Hence, in my case the "../../../utils" path was successfully resolved! Because it matches utils from angular_devkit itself

 /Users/amakhrov/Projects/angular-testing/node_modules/@angular-devkit/build-angular/src/utils/index.js

Do you think it's possible that this check can potentially give false positives for some arbitrary user module alias, if it also happens to match some internal module from devkit?

[alan-agius4]

@amakhrov, glad you hear that you had a good experience contributing to the Angular CLI. 😁

I do think that there are some rare edge cases, where using require.resolve(request) might cause undesired behavior. A more correct way would be to changing the resolutions paths to use the workspace root path. require.resolve(request, { paths: [wco.root] }).

[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.}