Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

JSDoc @import _unintentional?_ passthrough to generated declarations. #58921

Open
1 task done
typhonrt opened this issue Jun 18, 2024 · 5 comments
Open
1 task done

JSDoc @import _unintentional?_ passthrough to generated declarations. #58921

typhonrt opened this issue Jun 18, 2024 · 5 comments
Assignees
Labels
Bug A bug in TypeScript Domain: Declaration Emit The issue relates to the emission of d.ts files Effort: Casual Good issue if you're already used to contributing to the codebase. Harder than "good first issue". Help Wanted You can do this

Comments

@typhonrt
Copy link

typhonrt commented Jun 18, 2024

Acknowledgement

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

Comment

With TS 5.5 and the new @import JSDoc tag it appears that TSC will passthrough the comment block containing @import to the generated declarations. The actual import statements are added, but the "unnecessary" comment block remains in the generated declarations. I've already discussed this with the maintainer of TypeDoc and a fix is put in there to ignore any @import comment blocks, but I figured it would be worth raising this as a potential issue with this new functionality. It's not broken, but can possibly be refined in respect to downstream tooling. I think it is fine to remove any JSDoc comment blocks that just contain @import tags from generated declarations.

I do have a full description of the scenario and the small inconvenience this can cause in downstream tooling via this TypeDoc issue, so do refer to that for an example.

I really appreciate @import though as it is a mighty fine feature!

@DanielRosenwasser DanielRosenwasser added Bug A bug in TypeScript Help Wanted You can do this Domain: Declaration Emit The issue relates to the emission of d.ts files Effort: Casual Good issue if you're already used to contributing to the codebase. Harder than "good first issue". labels Jun 19, 2024
@DanielRosenwasser DanielRosenwasser added this to the TypeScript 5.6.0 milestone Jun 19, 2024
@a-tarasyuk
Copy link
Contributor

@DanielRosenwasser @weswigham Should @param tags be removed because they use types from the @import tag? Or should only the @import tags be removed?

/** @import Foo, { I } from "./a" */
/**
 * @param {Foo} a
 * @param {I} b
 */
export function foo(a: Foo, b: I): void;
import type Foo from "./a";
import type { I } from "./a";

@DanielRosenwasser
Copy link
Member

Hm, I'm not sure - I'd have to defer to @weswigham. I would probably just keep them to reuse as much as possible.

@typhonrt
Copy link
Author

The @param and anything else is important to keep for generating API docs from type declarations with say TypeDoc. This should be limited to just the @import JSDoc comment block and quite likely only if that comment block contains just @import statements.

@a-tarasyuk
Copy link
Contributor

In this case, the type references will be unavailable. Is it ok? or should we convert the types to import() calls?

@typhonrt
Copy link
Author

typhonrt commented Jun 24, 2024

In this case, the type references will be unavailable. Is it ok? or should we convert the types to import() calls?

@a-tarasyuk Perhaps you can clarify this a little more. Things are working as expected except the passthrough of @import comment block is unnecessary.


In regard to @import it's a directive to generate the the import type ... statements in the declaration and is not semantically relevant beyond that. In the example given above the generated types is all fine and desired:

import type Foo from "./a";
import type { I } from "./a";

The actual JSDoc comment block has no real meaning to downstream tooling beyond TSC and the imports (Foo / I) are available.

Consider the case of bundling type declarations as well where the particular paths referenced from the @import tags are irrelevant in the case of local files in respect to the bundle. If the above file and others where references like ./a, ./some-path/b those references are meaningless in the bundled types. When bundling types import type Foo from "./a" will pull Foo into the bundle, so additional JSDoc comment blocks that reference @import Foo from './a' are not necessary to be in the bundled types.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug A bug in TypeScript Domain: Declaration Emit The issue relates to the emission of d.ts files Effort: Casual Good issue if you're already used to contributing to the codebase. Harder than "good first issue". Help Wanted You can do this
Projects
None yet
Development

No branches or pull requests

4 participants