JSDoc typedef imports are emitted with a resolved path to node_modules

[bashmish]

🔎 Search Terms

"JSDoc", "typedef", "node_modules", "resolved"

🕗 Version & Regression Information

• This is the behavior in every version I tried, and I reviewed the FAQ for entries about common bugs

⏯ Playground Link

https://stackblitz.com/edit/issue-ts-jsdoc-typedef-resolved-node-modules?file=issue.js,dist-types%2Fissue.d.ts

In the StackBlitz example you can run npm run build:watch to play with the input and output of issue.js.

💻 Code

/**
 * @typedef {import('@lion/ajax').LionRequestInit} LionRequestInit
 */

export class NewAjax {
  /**
   * @param {LionRequestInit} init
   */
  case1_works(init) {}

  /**
   * @param {LionRequestInit?} init
   */
  case2_works(init) {}

  /**
   * @param {LionRequestInit=} init
   */
  case3_works(init) {}

  /**
   * @type {(init?: LionRequestInit) => void}
   */
  case4_works(init) {}

  /**
   * @param {LionRequestInit} [init]
   */
  case5_unexpectedlyResolvesPathToNodeModules(init) {}
}

/**
 * @type {(init?: LionRequestInit) => void}
 */
// @ts-expect-error
NewAjax.prototype.case6_unexpectedlyResolvesPathToNodeModules;

🙁 Actual behavior

For some cases (case5 and case6) the emitted .d.ts files contains a path to node_modules, which is not needed and when published to NPM as part of my library will not resolve correctly.

/**
 * @typedef {import('@lion/ajax').LionRequestInit} LionRequestInit
 */
export class NewAjax {
    /**
     * @param {LionRequestInit} init
     */
    case1_works(init: LionRequestInit): void;
    /**
     * @param {LionRequestInit?} init
     */
    case2_works(init: LionRequestInit | null): void;
    /**
     * @param {LionRequestInit=} init
     */
    case3_works(init?: LionRequestInit | undefined): void;
    case4_works(init?: LionRequestInit): void;
    /**
     * @param {LionRequestInit} [init]
     */
    case5_unexpectedlyResolvesPathToNodeModules(init?: import("./node_modules/@lion/ajax/dist-types/types/types.js").LionRequestInit | undefined): void;
    /**
     * @type {(init?: LionRequestInit) => void}
     */
    case6_unexpectedlyResolvesPathToNodeModules: (init?: import("./node_modules/@lion/ajax/dist-types/types/types.js").LionRequestInit | undefined) => void;
}
export type LionRequestInit = import('@lion/ajax').LionRequestInit;

🙂 Expected behavior

case5 and case6 work the same as all others, just having methodName(init?: LionRequestInit | undefined): void;

Additional information about the issue

I'm using case6 to define method types without overriding it, because it's indirectly supporting smth that the parent class does not. So I'm intertested to make it work. Workarounds like case2-3-4 are not suitable for me.

[remcohaszing]

This happens consistently if TypeScript is unable to resolve a type from public exports based on inference.

This particular case looks different though.