Using `jsdoc/no-undefined-types` without actually checking if types are undefined.

[jespertheend]

Motivation

I would like to use types in jsdoc without having to use import().
For instance, instead of doing

/** @type {import("../../../../some/very/long/path.js").MyStruct} */
const obj = {
    // ...
}

I would like to do

import {MyStruct} from "../../../../some/very/long/path.js";

/** @type {MyStruct} */
const obj = {
    // ...
}

However, at the moment this causes an eslint no-unused-vars error.
Afaik the only way to solve this is by enabling jsdoc/no-undefined-types, however, this causes errors when using certain types like Generator or ConstructorParameters. If #99 is added we can import the same files that are used for typescript.
But until then the only way to suppress these errors is by providing a list of types in definedTypes for jsdoc/no-undefined-types, which is not ideal.

Would there be some sort of way to use jsdoc/no-undefined-types for suppressing no-unused-vars errors only? That is, mark variables as used without actually checking if the used type is a valid type?

---

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[jaydenseric]

It's not good to import something just for use in JSDoc types. That has runtime costs; the module is importing something it doesn't actually need to function. If you run the module in the browser, it will have to needlessly load the imported module before the actual module code can run. If you are run the module in Deno it will have to download and cache that import. If you run the module with Node.js the import will have to be resolved.

You can't import JSDoc typedefs using a runtime import statement, so it's limited to real module exports anyway which only makes up some of the types you use in JSDoc.

If you happen to already import and use the thing in the module, because it's actually needed by the runtime code, then that's another story.

[jespertheend]

I’m aware that importing things without using them is bad. But in my case the types are being used elsewhere in the application, just not in the same file. So I figured importing these things wouldn’t have a lot of overhead.

Another solution for this problem is @typedef importing everything. But until microsoft/TypeScript#46011 is fixed that is not ideal either.

[brettz9]

Let's track this in #858 instead. Feel free to subscribe there in case any updates are forthcoming... Thanks...