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

Question about type definitions #1197

Closed
jsumners-nr opened this issue Feb 6, 2024 · 3 comments
Closed

Question about type definitions #1197

jsumners-nr opened this issue Feb 6, 2024 · 3 comments
Labels

Comments

@jsumners-nr
Copy link

In jsdoc type definitions are picked up regardless of the file they are defined in. Consider:

foo.js

'use strict'

/**
 * Foo is an interface not a class.
 *
 * @interface
 * @private
 */
class Foo {
  /**
   * The name of the thing.
   *
   * @type {string}
   */
  name
}

module.exports = Foo

bar.js

'use strict'

/**
 * Bar is a Foo
 *
 * @extends Foo 
 */
class Bar extends Foo {
  /**
   * The answer to everything.
   *
   * @type {number}
   */
  answer = 42

  constructor() {
    super()
    this.name = 'Bar'
  }
}

module.exports = Bar

Running jsdoc -p *.js on the above will result in an out/index.html that shows a Bar definition that links back to Foo:

image

But if we have the jsdoc/no-undefined-types rule enabled for this eslint plugin we will get an error in bar.js about Foo being undefined. I think #99 is discussing this same problem, but I'm not clear what the resolution is. Are we able to configure this plugin to work as jsdoc does?

@brettz9
Copy link
Collaborator

brettz9 commented Feb 6, 2024

ESLint lints one file at a time, so if you don't import the variables (e.g., by using ESM), it won't be aware of them.

So the no-undefined-types rule is indeed limited. You can disable this particular rule or use an ESLint disable directive to suppress individual errors, if you wish.

jsdoc, the tool, defined a popular syntax which has since become refined by TypeScript. One can use TypeScript-flavored jsdoc within plain JavaScript without need for TypeScript syntax (using the allowJs and optionally checkJs tsconfig.json options). The original jsdoc project has been fairly stagnant in terms of updating its syntax, and since there are other tools such as typedoc which work with (TypeScript-flavored) jsdoc syntax as well, I would personally recommend projects go the TypeScript-flavored jsdoc route. One can express types more readily, as well as export types such that other projects can benefit from Intellisense auto-complete and tooltips which display the types.

@jsumners-nr
Copy link
Author

So the no-undefined-types rule is indeed limited. You can disable this particular rule or use an ESLint disable directive to suppress individual errors, if you wish.

Thank you. That's what I expected to be the case.

jsdoc, the tool, defined a popular syntax which has since become refined by TypeScript. One can use TypeScript-flavored jsdoc within plain JavaScript without need for TypeScript syntax (using the allowJs and optionally checkJs tsconfig.json options). The original jsdoc project has been fairly stagnant in terms of updating its syntax, and since there are other tools such as typedoc which work with (TypeScript-flavored) jsdoc syntax as well, I would personally recommend projects go the TypeScript-flavored jsdoc route. One can express types more readily, as well as export types such that other projects can benefit from Intellisense auto-complete and tooltips which display the types.

This does not seem relevant to the question asked. In particular, it does not apply to JavaScript projects.

@brettz9
Copy link
Collaborator

brettz9 commented Feb 6, 2024

It does apply to JavaScript projects. TypeScript tooling and documentation generation can be used with plain JavaScript. That's what I was talking about with the allowJs option.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants