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

Disallow {[string]} array notation #495

Closed
yvele opened this issue Feb 24, 2020 · 6 comments · Fixed by #586
Closed

Disallow {[string]} array notation #495

yvele opened this issue Feb 24, 2020 · 6 comments · Fixed by #586

Comments

@yvele
Copy link

yvele commented Feb 24, 2020

I know that the {[string]} array notation doesn't exists at all.. but I can find it quite often in my company code base, and I would like to restrict it (ideally with an auto fix). Does that make sense?

Is it possible to disallow and fix this kind of array notation?

❌ This should be disallowed

/**
 * @param {[string]} foo
 */

And fixed depending on preferredTypes to either

/**
 * @param {Array<string>} foo
 */
/**
 * @param {Array.<string>} foo
 */
/**
 * @param {string[]} foo
 */
@brettz9
Copy link
Collaborator

brettz9 commented Feb 25, 2020

[string] is a valid type for tuples in TypeScript: https://www.typescriptlang.org/docs/handbook/basic-types.html#tuple .

Both jsdoc and Closure have open issues to add this support. (There are also issues filed with closure and jsdoc which may also be of interest in seeking to add a way for jsdoc to add names for the components (Tuple in the case of the closure feature request); but these are not supported in jsdoctypeparser.)

There is a jsdoctypeparser issue filed, but the PR I put together for it needs research toward which rule differences exist for which modes, and I haven't found time for this research. However, I should be able to complete the PR earlier and just add to the different modes gradually, such as treating tuples as disallowed for "settings":{"jsdoc":{"mode": "jsdoc"}} and "settings":{"jsdoc":{"mode": "closure"}} (and tying it to a settings.jsdoc.modeVersion or mode: ["jsdoc", <version>] as well in case future versions of jsdoc/Closure do support this). But still would need time to get to it (or someone to revise the PR).

So that aspect is really a jsdoctypeparser, but as with your other issue recently filed, the fixer does have something for us to fix on our end.

@yvele
Copy link
Author

yvele commented Feb 25, 2020

Thanks for the super explicit and referenced clarification! (I like your style 👍 )

Yeah, I would like to disable the tuple type in projects that doesn't use TypeScript

@brettz9
Copy link
Collaborator

brettz9 commented Feb 27, 2020

Closing as this is effectively a dupe of part of #356, though I have made explicit mention there of this use case.

@brettz9 brettz9 closed this as completed Feb 27, 2020
@yvele
Copy link
Author

yvele commented Apr 9, 2020

Hum FYI I just remembered where I saw the {[type]} array notation back in 2017: jsdoc/jsdoc#1073 (comment)

/**
 * Foo function.
 *
 * @param {[number, string]} bar - The bar array.
 */
function foo(bar) {}

@yvele

This comment has been minimized.

brettz9 added a commit to brettz9/eslint-plugin-jsdoc that referenced this issue Jun 19, 2020
…are type parsing; fixes part of gajus#356; fixes gajus#495

BREAKING CHANGE:

Requires Node 10+

Also:
1. Adds "permissive" mode
2. Checks "param" for valid namepaths
brettz9 added a commit to brettz9/eslint-plugin-jsdoc that referenced this issue Jun 20, 2020
…are type parsing; fixes part of gajus#356; fixes gajus#495

BREAKING CHANGE:

Requires Node 10+

Also:
1. Adds "permissive" mode
2. Checks "param" for valid namepaths
brettz9 added a commit to brettz9/eslint-plugin-jsdoc that referenced this issue Jun 20, 2020
…are type parsing; fixes part of gajus#356; fixes gajus#495

BREAKING CHANGE:

Requires Node 10+

Also:
1. Adds "permissive" mode
2. Checks "param" for valid namepaths
brettz9 added a commit to brettz9/eslint-plugin-jsdoc that referenced this issue Jun 20, 2020
…are type parsing; fixes part of gajus#356; fixes gajus#495

BREAKING CHANGE:

Requires Node 10+

Also:
1. Adds "permissive" mode
2. Checks "param" for valid namepaths
3. Refactors to use updated/better Node 10+ syntax/packages
brettz9 added a commit that referenced this issue Jun 21, 2020
…are type parsing; fixes part of #356; fixes #495 (#586)

BREAKING CHANGE:

Requires Node 10+

Also:
1. Adds "permissive" mode
2. Checks "param" for valid namepaths
@gajus
Copy link
Owner

gajus commented Jun 21, 2020

🎉 This issue has been resolved in version 28.0.0 🎉

The release is available on:

Your semantic-release bot 📦🚀

@gajus gajus added the released label Jun 21, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants