Suggest imports to self-reference a package by its name when it has an exports
field
#54080
Open
5 tasks done
Labels
Awaiting More Feedback
This means we'd like to hear from more people who would be helped by this feature
Domain: Auto-import
Suggestion
An idea for TypeScript
Suggestion
π Search Terms
Package self reference auto import
β Viability Checklist
My suggestion meets these guidelines:
β Suggestion
Node.js supports self-referencing a package using its name when it has an
exports
field. 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 nearestpackage.json
and if it has aname
andexports
field, importing that package name resolves there. This works correctly withmoduleResolution
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 itsimports
.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 theexports
field. I don't think this really conflicts with that issue since the problem there is that withoutexports
, it can lead to imports likemy-pkg/src/something
which you don't want but since package self-referencing like this requires anexports
field, imports like that wouldn't be allowed.π Motivating Example
Let's say you have a package that looks like this:
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 withmoduleResolution
bundler
/nodenext
but with this feature, the suggested import would be tomy-package
rather than./index.js
.π» Use Cases
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.
The text was updated successfully, but these errors were encountered: