Skip to content

Enable the JSDoc rule valid-types - #13486

Closed
afercia wants to merge 23 commits into
WordPress:trunkfrom
afercia:jsdoc-valid-types
Closed

afercia wants to merge 23 commits into
WordPress:trunkfrom
afercia:jsdoc-valid-types

Conversation

@afercia

@afercia afercia commented Sep 11, 2026 •

Copy link
Copy Markdown
Contributor

See https://core.trac.wordpress.org/ticket/66033

  • Enables the JSDoc rule jsdoc/valid-types.
  • Todo: Fix all the reported violations.

There are 69 violations of the valid-types rule. @westonruter since you are the types master, would you like to take care of this fix? Just run npm run lint:jsdoc and fix all the reported violations.

Use of AI Tools

AI assistance: Yes
Tool(s): Local Ollama service with Continue in VSCode
Model(s): qwen3.8:27b-mlx
Used for: Research JSDoc fixes. Final implementation checked by me.


This Pull Request is for code review only. Please keep all other discussion in the Trac ticket. Do not merge this Pull Request. See GitHub Pull Requests for Code Review in the Core Handbook for more details.

@github-actions

Copy link
Copy Markdown

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

Core Committers: Use this line as a base for the props when committing in SVN:

Props afercia.

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

@github-actions

Copy link
Copy Markdown

Test using WordPress Playground

The changes in this pull request can previewed and tested using a WordPress Playground instance.

WordPress Playground is an experimental project that creates a full WordPress instance entirely within the browser.

Some things to be aware of

  • All changes will be lost when closing a tab with a Playground instance.
  • All changes will be lost when refreshing the page.
  • A fresh instance is created each time the link below is clicked.
  • Every time this pull request is updated, a new ZIP file containing all changes is created. If changes are not reflected in the Playground instance,
    it's possible that the most recent build failed, or has not completed. Check the list of workflow runs to be sure.

For more details about these limitations and more, check out the Limitations page in the WordPress Playground documentation.

Test this pull request with WordPress Playground.

wporg-sync pushed a commit that referenced this pull request Sep 21, 2026
Enables the JSDoc rule `valid-types` and fixes all the reported violations.
Part of the effort to improve JS inline documentation for 7.2.

Developed in #13486

See #66033.


git-svn-id: https://develop.svn.wordpress.org/trunk@63766 602fd350-edb4-49c9-b593-d223f7449a82
wporg-sync pushed a commit to WordPress/WordPress that referenced this pull request Sep 21, 2026
Enables the JSDoc rule `valid-types` and fixes all the reported violations.
Part of the effort to improve JS inline documentation for 7.2.

Developed in WordPress/wordpress-develop#13486

See #66033.

Built from https://develop.svn.wordpress.org/trunk@63766


git-svn-id: http://core.svn.wordpress.org/trunk@62938 1a063a9b-81f0-0310-95a4-ce76da25c4cd
@afercia

afercia commented Sep 21, 2026

Copy link
Copy Markdown
Contributor Author

@afercia afercia closed this Sep 21, 2026
@afercia
afercia deleted the jsdoc-valid-types branch September 21, 2026 06:36

@westonruter westonruter left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@afercia A post-commit review for you.

Comment on lines -829 to -839
* @param {wpList~confirm} settings.confirm Callback that's run before a request is made. Default: null.
* @param {wpList~addBefore} settings.addBefore Callback that's run before an item gets added to the list.
* Default: null.
* @param {wpList~addAfter} settings.addAfter Callback that's run after an item got added to the list.
* Default: null.
* @param {wpList~delBefore} settings.delBefore Callback that's run before an item gets deleted from the list.
* Default: null.
* @param {wpList~delAfter} settings.delAfter Callback that's run after an item got deleted from the list.
* Default: null.
* @param {wpList~dimBefore} settings.dimBefore Callback that's run before an item gets dim'd. Default: null.
* @param {wpList~dimAfter} settings.dimAfter Callback that's run after an item got dim'd. Default: null.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not familiar with this ~ syntax. It does seem unnecessary regardless. However, with TypeScript we could potentially re-introduce some flavor of that.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

JSDoc doesn't validate them. Not sure that ~ syntax is still valid. JSDoc can't understand it anyways. After all these are all callback functions. We will see when you will extend TypeScript to this file.

/**
* Adds event that opens the time stamp form if the form is hidden.
*
* @listens $edittimestamp:click

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why did these @listens tags need to be removed? They seem valid: https://jsdoc.app/tags-listens

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same: JSDoc doesn't validate them. It doesn't understand this 'path'. Also, not sure what value these @listens tag may add because the function is self-explanatory.... when I read:
$edittimestamp.on( 'click', ....
I already see what I need to know.
That said, if you can find a way to make JSDoc understand these @listens and not report a violation, I'm all for it.

* @param {{beforeSend}, *} options Additional options for the sync.
* @param {string} method The CRUD method ("create", "read", "update", or "delete") to be performed.
* @param {Backbone.Model} model The model to be synced.
* @param {Object} options Additional options for the sync.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is now less-specific than before. It seems like it should have been something like this:

Suggested change
* @param {Object} options Additional options for the sync.
* @param {Object} options Additional options for the sync.
* @param {Function} [options.beforeSend] Callback to run before sending.
* @param {Function} [options.success] Callback executed on a successful request.
* @param {Function} [options.error] Callback executed on a failed request.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't see options.success or options.error here, while I do see options.complete. I will add it.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

They are documented in Backbone's options: https://backbonejs.org/#Sync

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see and all other jQuery request options
Does that mean we should really document ALL those options? I'd say no, and maybe we should just keep the main options object.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Probably, not, no. Let's just do beforeSend.

* @param {string} method The CRUD method ("create", "read", "update", or "delete") to be performed.
* @param {Backbone.Model} model The model to be synced.
* @param {{success}, *} options Additional options for the sync.
* @param {Object} options Additional options for the sync.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ditto above.

Comment on lines -278 to -281
/**
* @static
* @type Array
*/

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Curious why this needs to be removed?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Again, JSDoc doesn't validate this. Also, is it a static? Looks like just a local vari to me.

Comment on lines -234 to -237
/**
* @static
* @type Array
*/

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also curious about this removal.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See above

Comment on lines -251 to -252
* @fires wp.media.controller.MediaLibrary#attachment:details:shift-tab
* @fires wp.media.controller.MediaLibrary#attachment:keydown:arrow

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why remove these here but they are kept elsehwere?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Because these ones aren't validated by JSDoc :)

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also, I don't understand the value added by these @fires tags. I can see what the function triggers... .trigger( 'attachment:details:shift-tab', event ); by just looking sat the code.

* handlers to prevent duplicate listeners.
*
* @since 4.0.0
* Listens for the `window:resize` event.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No @listens?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same as above. JSDoc doesn't understand @listens window:resize and honestly these listens tags are useless.

* in the options.
*
* @since 3.5.0
* Fires `collection:reset`.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why no @fires?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same as above.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why no @fires?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same as above

@afercia afercia mentioned this pull request Sep 22, 2026
@afercia afercia added the props-bot Adding this label triggers the Props Bot workflow for a PR. label Sep 22, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

props-bot Adding this label triggers the Props Bot workflow for a PR.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants