You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Auto imports not working for modules exported via exports in package.json #46339
Auto import not working as expected for modules that use the exports field and type: module in package.json.
Relevant PR that introduced exports support: #44501
🕗 Version & Regression Information
Occurs in 4.5.0-dev.20211012 and 4.5.0-beta.
⏯ Playground Link
It's a bit hard to reproduce in the playground, so I've created a repository here https://github.com/renke/typescript-4.5-beta-exports – The README contains some instructions on how to reproduce it. It also describes another bug that was already filed here #46333 so it can probably be ignored.
🙁 Actual behavior
Auto import doesn't work for non-root exported modules (unless they are already imported elsewhere).
Also, ./* exports can not be imported at all.
Running the modules via node works, so the exports configuration should be valid.
🙂 Expected behavior
Auto import should work for all modules explicitly exported via exports when the exporting package is listed in dependencies (as in #38923).
Also, import (and auto import) should work for ./* exports. Unclear if this would lead to performance problems for auto import, but I think this should be supported.
To clarify, is this a problem only when the importing project is using the new node12 and nodenext module resolution modes, or does this happen even for old modes?
So my understanding is that module node12 or nodenext (or more specifically the new module resolution it implies) are what actually enables the interpretation of the exports field .
For old resolutions one has to resort to the types field and a declarations file and deal with the fact that only one (the root?) module is actually available for auto import (although there a few workarounds as used by rxjs and the like). That's what I am doing in the exporter-old package.
Exposing multiple (sub)modules was not supported prior to the exports support. Exposing all modules (meaning ./* in exports) was not supported at all.
What usually worked (using the node resolution) is importing a module manually, but with the drawback that one has to specify the exact path to the given module (in my repository one would have to include the lib directory). Of course you can do a few tricks with path mappings, but the burden here is on the consumer which I would like to avoid.
At least that's my understanding after doing a bit of research in the past. Naturally, I don't know what TypeScript is doing internally.
Activity
andrewbranch commentedon Oct 13, 2021
To clarify, is this a problem only when the importing project is using the new
node12andnodenextmodule resolution modes, or does this happen even for old modes?renke commentedon Oct 13, 2021
So my understanding is that module
node12ornodenext(or more specifically the new module resolution it implies) are what actually enables the interpretation of theexportsfield .For old resolutions one has to resort to the
typesfield and a declarations file and deal with the fact that only one (the root?) module is actually available for auto import (although there a few workarounds as used by rxjs and the like). That's what I am doing in theexporter-oldpackage.Exposing multiple (sub)modules was not supported prior to the
exportssupport. Exposing all modules (meaning./*inexports) was not supported at all.What usually worked (using the
noderesolution) is importing a module manually, but with the drawback that one has to specify the exact path to the given module (in my repository one would have to include thelibdirectory). Of course you can do a few tricks with path mappings, but the burden here is on the consumer which I would like to avoid.At least that's my understanding after doing a bit of research in the past. Naturally, I don't know what TypeScript is doing internally.
andrewbranch commentedon Jan 24, 2022
This should be fixed by #47092