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

originally raised at https://github.com/typescript-eslint/typescript-eslint/issues/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

Use the issue's my-project/src/index.ts example with some-package/src/foo and some-package/dist/foo as the initial cases, alongside the shown package.json and tsconfig.json layout. Define the rule's behavior around imports of src/foo.ts when corresponding compiled .js and .d.ts files exist, and verify that the fail and pass cases produce the intended diagnostics.