Wrong auto import paths for entry points

[cyrilletuzi]

TypeScript Version: 2.9.0-dev.20180330

Search Terms: imports, index

Code

With the following very common architecture :

src/
|- external.ts
|- feature/
    |- feature.ts
    |- index.ts
    |- internal.ts

with feature.ts :

export class Feature {}

and index.ts as an entry point for this feature :

export { Feature } from './feature';

Then, try to auto-import Feature from external.ts and from internal.ts.

Expected behavior:

From external.ts, it should :

import { Feature } from "./feature/index";

(without index if moduleResolution is set to node).

From internal.ts, it should :

import { Feature } from "./feature";

Actual behavior:

From external.ts, it's OK :

import { Feature } from "./feature/index";

From internal.ts, it's also importing from the entry point, instead of directly from the file :

import { Feature } from "./index";

worse with moduleResolution set to node, as it will do this :

import { Feature } from ".";

Related Issues:
The current behavior was introduced for the opposite issue : for libs, imports must be from entry points and not from deep imports (otherwise it causes errors). So for now, TypeScript always choose the shortest path.

But inside a lib/feature, imports must be done from deep imports and not from entry points. Otherwise, it really often create circular dependencies issues (which, by the way, are really difficult to debug).

TypeScript should be smarter and do auto-imports as follow :

• for libs (node_modules and TS custom paths), choose the shorter path ;
• inside the project, if the file we're in is in the same directory (like internal.ts) or a subdirectory than the entry point (index.ts), choose the deep import ;
• otherwise, choose the shortest path.

From internal.ts, it should : import { Feature } from "./feature/feature";`

But you're in feature/internal and that's a relative path, so wouldn't it be accessing feature/feature/feature ?

[cyrilletuzi]

It was just a typo, edited.

[cyrilletuzi]

I wouldn't say it's just a suggestion. In many cases it produces broken code that won't work, so for me it's a bug.

it produces broken code that won't work

What's the failure you're getting?

[cyrilletuzi]

It's not a compilation failure, TS will be OK to compile it, but then there will be execution failures, which completely depends on the code you're doing.

The general problem is that importing from the entry point when you're inside a lib/feature really often create circular dependencies errors.

[cyrilletuzi]

What feedback do you need to take this issue seriously? I don't understand why such issues, which are not special cases at all but very common use cases and day to day development are just ignored.

Should be fixed by #23623, test it out in the next nightly build