Repository: TypeScript
Issue: Suggest imports to self-reference a package by its name when it has an `exports` field 
Labels: Suggestion,Awaiting More Feedback,Domain: Auto-import

# Suggestion

<!--
  Please fill in each section completely. Thank you!
-->

## 🔍 Search Terms

<!--
  💡 Did you know? TypeScript has over 2,000 open suggestions!
  🔎 Please search thoroughly before logging new feature requests as most common ideas already have a proposal in progress.
  The "Common Feature Requests" section of the FAQ lists many popular requests: https://github.com/Microsoft/TypeScript/wiki/FAQ#common-feature-requests

  Replace the text below:
-->

Package self reference auto import 

## ✅ Viability Checklist

<!--
   Suggestions that don't meet all these criteria are very, very unlikely to be accepted.
   We always recommend reviewing the TypeScript design goals before investing time writing
   a proposal for ideas outside the scope of the project.
-->
My suggestion meets these guidelines:

* [x] This wouldn't be a breaking change in existing TypeScript/JavaScript code
* [x] This wouldn't change the runtime behavior of existing JavaScript code
* [x] This could be implemented without emitting different JS based on the types of the expressions
* [x] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
* [x] This feature would agree with the rest of [TypeScript's Design Goals](https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals).


## ⭐ Suggestion

Node.js supports [self-referencing a package using its name when it has an `exports` field](https://nodejs.org/dist/latest-v18.x/docs/api/packages.html#self-referencing-a-package-using-its-name). Note this is distinct from self-referencing a package working in some monorepo setups where there are symlinks from node_modules to the packages. This doesn't rely on any symlinks, it looks up to the nearest `package.json` and if it has a `name` and `exports` field, importing that package name resolves there. This works correctly with `moduleResolution` `nodenext`/`bundler` but TypeScript doesn't suggest auto-imports to the package name or have completions to the package name in import specifiers, it would be nice if it did.

This is essentially the same request as #52460 but about a package's own `exports` rather than its `imports`.

This is also sort of a request for the opposite behaviour than requested in #26044 except that this is specifically only about packages that have an `exports` field where TypeScript is configured to use the `exports` field. I don't think this really conflicts with that issue since the problem there is that without `exports`, it can lead to imports like `my-pkg/src/something` which you don't want but since package self-referencing like this requires an `exports` field, imports like that wouldn't be allowed.

## 📃 Motivating Example

Let's say you have a package that looks like this:

```jsonc
// package.json
{
  "name": "my-package",
  "type": "module",
  "exports": "./index.js"
}
```

```js
// index.js
export function doSomething() {}
```

```ts
// index.d.ts
export declare function doSomething(): void;
```

And you'd like to write tests that reference the package name so it's easy to see that the tests only use the package's public API specified in `exports`, you can already do this and it will correctly compile with `moduleResolution` `bundler`/`nodenext` but with this feature, the suggested import would be to `my-package` rather than `./index.js`.

```ts
// index.test.ts
import { doSomething } from 'my-package';

// some tests...
```

<!--
  If you were announcing this feature in a blog post, what's a short explanation that shows
  a developer why this feature improves the language?
-->

## 💻 Use Cases

<!--
  What do you want to use this for?
  What shortcomings exist with current approaches?
  What workarounds are you using in the meantime?
-->
As mentioned above, being able to easily write tests that only use a package's public API in the same way that users would use it via the package name without having to work around auto-import by changing the import after auto-import suggests a relative path.