lsp: unable to import types in JSDoc

[jaydenseric]

In regular TypeScript projects, within a .js file with type checking enabled via // @ts-check you can import types from other files within JSDoc comments. For example…

In a.js:

// @ts-check

/**
 * Description for A.
 * @param {import("./b.js").default} b The B.
 */
export default function a(b) {
  return b;
}

In b.js:

// @ts-check

/**
 * Description for B.
 * @type {boolean}
 */
export default true;

Note that the parameter type is able to be imported and checked:

With exactly the same setup in a Deno project, the parameter type cannot be imported or checked:

This not working in Deno, with no open issues about it has really made the past few days trying to get an isomorphic codebase with a mixture of .ts, .tsx, and .js files a nightmare, because it's hard to tell if it's you or Deno that's doing the wrong thing. I think if this Deno bug were fixed I'd finally have a workable solution!

[jaydenseric]

Has any investigation on this happened yet; is this an easy or hard bug to fix?

If it's a low-hanging fruit, patching this would be a game changer for those of us trying to develop and publish isomorphic library code with type safety. Type checking is practically impossible for universal browser/Deno modules until this is fixed.

[jaydenseric]

Here is an example of a type importable in a .ts file:

import type { Context } from "https://deno.land/x/[email protected]/mod.ts";

As you can see, attempting to import it for use in a JSDoc @typedef doesn't work:

// @ts-check
/** @typedef {import("https://deno.land/x/[email protected]/mod.ts").Context} Context */

It is a really mysterious thing why importing types in JSDoc sometimes works, and sometimes doesn't. It seems to never work when you import a type from a .ts file into JSDoc in a .js file though.

This issue hasn't been investigated or fixed in the nearly 3 months since it was filed in June 😢

I'm sure in time Deno will shape up to be the dream JS/TS runtime and I appreciate the efforts of the Deno collaborators and contributors, but IMO the Deno team needs to focus more on unblocking package authors that are working hard pro-bono to build out packages to grow the Deno ecosystem. Bugs that are showstoppers for type checking (e.g. #11362 , #12143 , #11786 (comment)), code coverage (e.g. #11327), etc. need to be dealt with with a sense of urgency instead of working on enhancements or nice-to-haves like Node.js ecosystem compatibility. That way both the Deno runtime and a useful ecosystem of packages can be developed in parallel, and the Deno API can evolve sooner to meet the needs of package authors.

[kitsonk]

Even though #13156 came long after, @jespertheend was able to isolate it in that issue, and changes are being made to fix the issue, so we will use #13156 for tracking purposes.

Closing this as a duplicate.