Fix incorrect resolution with relative imports on project dependencies

[voliva]

I ran across #83 on my project, where I have a dependency which has a relative import to a file that happens to have the same name as one of my roots.

I think the issue is on this line: It's checking for the resolved innerRequest, which strips the relative prefix for dependencies. I think that what it should be is if the original non-resolved request (request.request).

With this change I no longer have this issue, but I'm not sure this is OK

[Rush]

rush@rushbox: /c/tsconfig-paths-webpack-plugin (relative-paths) 1.08s » yarn build
yarn run v1.22.11
warning ../package.json: No license field
$ rimraf lib && tsc -p src/tsconfig.lib.json
src/plugin.ts:248:7 - error TS2532: Object is possibly 'undefined'.

248       request.request.startsWith(".") ||
          ~~~~~~~~~~~~~~~

src/plugin.ts:249:7 - error TS2532: Object is possibly 'undefined'.

249       request.request.startsWith("..")
          ~~~~~~~~~~~~~~~

[Rush]

Please see voliva#1

[jonaskello]

@voliva @Rush Do you think this is tested enough to be merged?

[Rush]

@jonaskello I am sorry but I do not have a well enough understanding of the project to say what was the intention of innerRequest and why changing it to request.request fixes the issue.

Also there aren't really any unit tests to tell us if anything regressed. I guess testing this is practice is the best bet. ;)

I hope @voliva can chime in as he did the original change and I merely made it publishable.

[jonaskello]

Ok, so we'll wait for now. If someone wants to contribute some unit tests that would of course be very helpful :-).

[voliva]

@jonaskello I am sorry but I do not have a well enough understanding of the project to say what was the intention of innerRequest and why changing it to request.request fixes the issue.

Also there aren't really any unit tests to tell us if anything regressed. I guess testing this is practice is the best bet. ;)

I hope @voliva can chime in as he did the original change and I merely made it publishable.

I'm in a similar situation - I ran across the issue, tried to debug it and I saw:

• innerRequest empirically gets a relative path without ./ prefix on dependencies.
• There was no occurrence where innerRequest would start with . and request.request didn't.
• Using the original request.request solved the issue and apparently no other issues surfaced.

But I'm not that familiar with the code or what each of these values mean, so I can't know for sure either if this is a good solution.

[cosmin-dev]

Can we merge this? I have the same issue

[Rush]

I've been using the forked version with the fix and it's been working flawlessly.

[voliva]

@jonaskello I'd say it's ready then :)

[jonaskello]

Ok, let's merge this then :-)

[jonaskello]

Released in 3.5.2