Declaration files built from JSDoc typedefs with optional parameters reference indirect dependency

Bug Report

🔎 Search Terms

jsdoc declaration files optional parameters .d.ts grandchild indirect dependency

🕗 Version & Regression Information

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

⏯ Playground Link

Can’t provide TypeScript playground because I don’t see an option to build JSDoc types. But I did create a contained repo.

💻 Code

child/index.js:

/**
 * @typedef {import('grandchild').Options} Options
 */

parent/index.js:

/**
 * @typedef PluginOptions
 * @property {import('child').Options} [childOptions]
 */

🙁 Actual behavior

parent/index.js compiles to:

export type PluginOptions = {
    childOptions?: import("grandchild").Options | undefined;
};

This causes problem because parent doesn’t have a direct dependency on grandchild

🙂 Expected behavior

parent/index.js compiles to:

export type PluginOptions = {
    childOptions?: import("child").Options | undefined;
};

Note that this works correctly if childOptions is not optional. As in, this:

/**
 * @typedef PluginOptions
 * @property {import('child').Options} childOptions
 */

Correctly compiles to:

export type PluginOptions = {
    childOptions: import('child').Options;
};

[Methuselah96]

I’m not expecting the declaration emitter to re-export any symbols, I’m expecting it recognize that it can’t reuse the underlying type if the underlying type uses an import since it might not have access to that dependency.

[Methuselah96]

In this case it’s invalid to use the originating declaration because it’s trying to import a package that it doesn’t have a dependency on. Why is that considered “not a defect” of the current heuristics?