Closed
Description
openedon Mar 27, 2024
🔎 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
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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment