Way to feed `no-undefined-types` additional files or have it auto-detect them (and finding unused types within the same set of files); avoid defects of tampering with `no-unused-vars`

[brettz9]

For no-undefined-types, I'd like a way to feed one's project files, whether:

1. Detected by static or dynamic import/require, with the entry file(s) determined by:
   1. a new eslint-plugin-jsdoc option
   2. use of main or exports in package.json
   3. use of jsdoc config
2. By a file being present in one's jsdoc config
3. If eslint-plugin-jsdoc were supplied an array of files for finding typedefs

I need more context because some of my types are in:

• A purely-comment-based typedefs.js file which includes external and generic types
• Other files and modules

I'd like it to report for:

/**
* @param {MyType}
*/

...where MyType is not defined anywhere within JSDoc typedefs/interfaces across all files. The corollary is thus not to report errors for:

// One file, such as `typedefs.js`
/**
* @typedef {object} MyType
*/
/**
* @interface AnotherType
*/

// Another file:
/**
* @param {MyType}
*/

/**
* @param {AnotherType}
*/

Thanks very much for the very useful plugin!

Update: While traversing files of a project, also consider supporting @inheritdoc per #765

---

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

[gajus]

https://github.com/gajus/eslint-plugin-flowtype#define-flow-type

[brettz9]

Given that JSDoc has its own means of expressing user custom types such as through @typedef and @interface, wouldn't JSDoc types make sense as the default way to feed in definitions (and without extra effort to redefine such types)?

[brettz9]

Btw, re: those PRs, I am quite impressed how intuitive your code is, that it looks very easy to make one... Will see if I can set aside some time for it...

[gajus]

Given that JSDoc has its own means of expressing user custom types such as through @typedef and @interface, wouldn't JSDoc types make sense as the default way to feed in definitions (and without extra effort to redefine such types)?

Misunderstood the original issue.

[bary12]

Generally, The ESLint-friendly way of doing this is exporting the types using /* exported MyType */ and importing them as /* global MyType */, this is also how ESLint suggests to deal with variables defined in different files in browser context (without modules) when using no-unused-vars and no-undef. I don't think there's a general need in the community for this feature, and exported/global can be satisfactory.

[brettz9]

@bary12 : Maybe you have misunderstood the request also? This is not talking about JavaScript variables representing types, but JSDoc types... I've updated my original post with some examples...

If you did actually mean leveraging exported/imported for JSDoc types, besides the fact that the no-unused-vars rule would be reported when the type was not used in code, it would be awfully cumbersome to import and export JSDoc types manually when the information was easily accessible elsewhere within JSDoc comments.

[bary12]

The rule treats JSDoc types defined in typedefs as normal variables. It scans the file for typedefs and adds them to the scope exactly like normal variables.

[brettz9]

Yes, but it only scans the current file... Note my reference in the updated comment to these being in different files.. If one has defined generic types like "PlainObject" in another file, one would have to copy the definitions back in to each file, which is very cumbersome...

[bary12]

Or use /* global PlainObject */, the same way as ESLint recommends doing for variables when you have no form of import/export, or even add PlainObject to the list of globals in eslintrc.

[brettz9]

Gotcha... Yes, that is better than pasting in the whole typedef and the list of globals in .eslintrc would at least work across files, but besides adding redundant work--adding comments to lint one's comments seems particularly wasteful--I don't think type information should be polluting variable information.

For one, it may mislead developers into thinking that such a variable is in use within the file. Secondly, this may distract from what the real globals are, with globals often being a temporary evil necessity that should be easier to quickly review and occasionally re-review for possible removal/conversion to modules; if types are mixed in there, it becomes harder to notice the real global variables in use. Thirdly, it may improperly allow variables as types where the variables of that name don't actually exist.