Offer auto-imports for all files in package.json `exports` wildcard directories

[pilaoda]

My npm lib module's package.json

  "name": "my-lib",
  "exports": {
        ".": {
            "require": "./dist/index.js",
            "types": "./dist/index.d.ts"
        },
        "./*": {
            "require": "./dist/*.js",
            "types": "./dist/*.d.ts"
        },
        "./**/*": {
            "require": "./dist/**/*.js",
            "types": "./dist/**/*.d.ts"
        }
    },

An app depends on this npm module and install it.
The vscode auto import only support types in import {A} from "my-lib" resolve to my-lib/dist/index.d.ts, and could not find the symbol and type in something like import {B} from "my-lib/utils" resolve to my-lib/dist/utils.d.ts.

[DanielRosenwasser]

I might be mistaken, but I'm fairly certain that ** is not a supported subpath pattern in Node.js.

So are you saying that the issue is that even though this package.json is incorrectly configured, TypeScript is not resilient in providing correct auto-imports?

[pilaoda]

Sorry I just learn that ./**/* is no need and only ./* can be enough for this situation.
But even thouth I delete the unnecessary ./**/* pattern and keep the ./* pattern, the auto import still not working for something like import {B} from "my-lib/xx/utils" which should resolve to ./node_modules/my-lib/dist/xx/utils.d.ts.
If I import it manually, it will be compiled successfully.
The real problem I think is that the ts language server in editor only search index.d.ts but ignore * pattern searching in a node_modules package.

[pilaoda]

More detailed example, my project has below structure:

- node_modules
   - my-lib
      - dist
         index.d.ts
         utils.d.ts
      package.json
- src
   main.ts

index.d.ts:

export declare const A: number;

utils.d.ts:

export declare const B: number;

package.json

{
  "name": "my-lib",
  "exports": {
        ".": {
            "require": "./dist/index.js",
            "types": "./dist/index.d.ts"
        },
        "./*": {
            "require": "./dist/*.js",
            "types": "./dist/*.d.ts"
        }
    }
}

During my developing in src/main.ts, If I type "A", the editor will help me auto add import {A} from "my-lib". If I type "B", the editor don't know where the symbol B is, so I need to add import {B} from "my-lib/utils" manually.

[andrewbranch]

This is a known limitation for performance reasons. Originally, auto-imports were never available from files that weren’t already in the program in some way (for files in external libraries, this usually means transitively referenced by a local project file). Then, we started scraping package.json dependencies to see what else we can offer that’s not already in the program. But when we do that, we only look at the package’s entry points (main/types and exports) and files transitively referenced by those entry points, so we can avoid arbitrarily deep FS hits.

For a package that doesn’t define exports, this means anything not transitively referenced from main/types is not offered for auto-import, despite being reachable by a manual import—so this limitation applies not only to packages with wildcard exports but also to packages with no exports.

Fully lifting this limitation would effectively mean doing a recursive read on all of every project’s direct dependencies. We could make up an arbitrary rule that says we’ll do this recursive read only if an exports wildcard directs us to do so, since the intent to make modules available is explicit there, leaving packages without exports out. But I think an explicit list of exports is generally considered better practice, and I don’t mind privileging packages that tell us up front what work we’re going to do. @DanielRosenwasser thoughts?

[DanielRosenwasser]

I think we would need to be careful here - before making this change, I would want to see an expansion of the TSServer perf suite that uses the artificial test cases you've used to measure auto-import performace. But the auto-import program looking through files covered under explicit subpath patterns in exports doesn't sound like the craziest thing.