Rule proposal: ban importing `.ts` files from packages in `node_modules` when compiled `d.ts` & `.js` files are available

[DetachHead]

originally raised at typescript-eslint/typescript-eslint#5815

Description

contrary to popular belief, when publishing npm packages it's actually a good idea to include the source code in the published package. this is because you can use the declarationMap compiler option to make ctrl+click navigate to the source code instead of the declarations.

unfortunately IDEs sometimes incorrectly suggest importing from the source code instead of the compiled code. i think there should be an eslint rule to warn against this

folder structure

my-project/
├── node_modules/
│   └── some-package/
│       ├── dist/
│       │   ├── index.js
│       │   ├── index.d.ts
│       │   ├── foo.js
│       │   └── foo.d.ts
│       ├── src/
│       │   ├── index.ts
│       │   └── foo.ts
│       ├── tsconfig.json
│       └── package.json
└── src/
    └── index.ts

Fail Cases

// my-project/src/index.ts
import {foo} from 'some-package/src/foo'

Pass Cases

// my-project/src/index.ts
import {foo} from 'some-package/dist/foo'

Additional Info

while this won't cause any runtime errors, i believe it's bad for performance as it causes typescript to unnecessarily re-compile the package, when it's already been compiled

[ljharb]

Since nobody would do it, on purpose or by accident, if the IDE didn’t suggest it, it seems like that might be the best first attempt to address this?

[DetachHead]

i think it's possible for someone to do it on purpose without realizing that it won't work at runtime, so i think fixing it in eslint is the best solution, but i agree fixing it in the IDE is important too (but that's more difficult to reproduce since vscode's behavior when it comes to suggesting imports is quite unpredictable)

[ljharb]

quite unpredictable

I certainly agree with that :-)