Path resolution is wrong when tsconfig baseUrl is used

[Alexandru Ciucă]

My project's tsconfig has a baseUrl set to src and the folder structure looks like this:

src/
  submodule1/
  submodule2/
  ...

Some example import patterns:

// in submodule2/subfolder/*.ts
import "submodule1/someFile";
import "../../submodule1/someOtherFile";
import "../someOtherFile";
import "submodule2/someOtherFile";
import "./sameFolderFile.ts";

I looked at the rule's source code and noticed the following: when the linting rule iterates the import statements and sees something that doesn't start with . (import paths like submodule1/*), then it insists on doing something like path.relative("src", "submodule1/someFile"), which just ends up resolving to ../submodule1 instead of submodule1. This is regardless of setting the basePath option or not.

I see this behavior is also reflected in the test fixtures, with imports like import("src/...."). This however doesn't make much sense to me. TypeScript would not even resolve such imports unless
a) the baseUrl is set to the parent of src, not src itself
b) There is an entry in tsconfig paths mapping src to some other folder
c) src is an actual node module
d) the moduleResolution option is set to classic instead of node (which has been deprecated for a long time)

Either way, depending on the type of import path (relative or not) we end up with two different behaviors, which is IMHO a bug.

[Vladimir Yakovlev]

This is a good finding however the fix is not coming and I think I'm going to archive the project soon. The reason is that the tslint project itself got deprecated and the current state of the rule still fits my needs.

import("src/....") a) b) c) d)

I think I put it this way because I normally set baseUrl to ".", no any paths records required.

[Alexandru Ciucă]

Thanks for the update. Until I am able to find an equivalent rule for eslint, the following hack workaround worked, if anyone else bumps into this problem: !*(../)submodule1/** whitelists the submodule1/ folder, for both cases of relative/non-relative path. It isn't perfect and it assumes there isn't another folder with the same name nested, but it does the job.