Jonas Kello

Having investigated further, the problem in this issue seems to be unrelated to the new node resolution of ESM. Instead it is related to tsconfig-paths not respecting the file extensions...

@cspotcode Yes, I think you are on to something here. The original intent of the stripping of some stuff like extensions were probably that node should be able to re-resolve...

@cspotcode Perhaps we could go in the direction of letting tsconfig-paths always decide the exact file and just pass that to node instead of having node re-resolve by removing info?...

Thinking more on the extension stripping. When using tsconfig-paths together with ts-node ts-node will add `.ts` to `require.extensions`. This means that tsconfig-paths will resolve to `.ts` files. This may be...

@katywings It is already covered by this test: https://github.com/dividab/tsconfig-paths/blob/2461cc9c0aa6f02f27c679d1344adaf35ff05cf7/test/data/match-path-data.ts#L128-L142

> If we return the path to the module's root directory, then tsconfig-paths doesn't need to know about those additional fields because node will resolve from there. Yes of course...

> I believe tsconfig-paths may not have found the exact file; it may have found the wrong one. Interesting, could you provide an example when it would find the wrong...

Just to clarify let me see if I understand how to re-create the problem: * Use tslint-loader with webpack. * Have a tslint.json file in the root of the project....

IIRC we actually used that package in the very beginning but then we had feature requests for inheritance and comments which, at least at that time, the tsconfig package did...

Yes that sounds like a good idea :-). Perhaps the tsconfig package is accepting PRs so we can add the features to that package?