How to trace/debug auto import suggestions?

[jedwards1211]

Acknowledgement

• I acknowledge that issues using this template may be closed without further explanation at the maintainer's discretion.

Comment

I'm authoring a package with

  "type": "module",
  "exports": {
    "./package.json": "./package.json",
    "./*": {
      "types": {
        "import": "./dist/*.d.ts",
        "default": "./dist/*.d.cts"
      },
      "import": "./dist/*.js",
      "default": "./dist/*.cjs"
    }
  },

When I install it in a new project I can't get tsserver to auto suggest any imports from these files (until I've manually added an import from a given file), regardless of module and moduleResolution settings.

How do I turn on debug logging that will help me figure out why tsserver isn't offering any auto import suggestions from my package?

I tried turning on "typescript.tsserver.log": "verbose" and looking at those logs but I don't see anything that sheds light on how tsserver is making decisions.

Is there any logging option for this? I've used traceResolution to debug module resolution issues that cause compile errors and it was super helpful, but import suggestions still seem like a black box.

[RyanCavanaugh]

There isn't a huge amount of logging in this code (see src/server/project.ts around line 2500 for the AutoImportProviderProject).

Given that package.json I'm guessing you have more than 10 entry points and are hitting the built-in perf limiter that turns off package enumeration. Have you already set the "Include package json auto imports" option to 'on'?

[jedwards1211]

Thanks for the tip, I figured there wasn't much public documentation of this.

Yes, I have more than 10 entry points, one per utility function so that I don't have to use any bundler to minimize the memory usage/startup time when importing in Node. I tried setting "Include package json auto imports" option to 'on' but unfortunately it didn't make a difference, eventually I'll see if I can attach a debugger to tsserver.

I'm seeing this same issue with the popular es-toolkit project too, a popular lodash replacement. Also, MUI advises people to configure TypeScript not to suggest top-level imports from their packages and import from their fine-grained entrypoints (of which there are hundreds) instead.

Obviously it would take a bit more startup work, but I think it would make more sense to limit based upon the total size of a package, or modules scanned thus far while building an index of suggestions, than the number of entrypoints, because a single entry point can be enormous (e.g. the old aws-sdk) and a package with hundreds of fine-grained entry points could be quite small in comparison.

[RyanCavanaugh]

Totally. We're rewriting auto-imports in TS7 and it'll have smarter bail-out heuristics.

If you can publish your package somewhere we can pull it, we could probably see why it's not getting picked up. Checking in tsgo would be even better, though.

[jedwards1211]

Okay, here's my package: https://www.npmjs.com/package/@jcoreio/utils?activeTab=code

Unlike many packages you'll see, I'm including CJS, ESM, source and declaration maps for both, and original source files in the published package, so that Jump to Definition brings up readable source code instead of just declaration files. I don't know if having all of those files somehow trips tsserver up?

I haven't gotten my feet wet with tsgo yet, need to try that