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

bump eslint-plugin-jsdoc #5269

Merged
merged 3 commits into from
May 3, 2022
Merged

bump eslint-plugin-jsdoc #5269

merged 3 commits into from
May 3, 2022

Conversation

turadg
Copy link
Member

@turadg turadg commented May 2, 2022

Description

The version we have would error when doing yarn install under Node 18. (not in its list of supported engines)

The latest version changed gajus/eslint-plugin-jsdoc#855 to align more with TypeScript. This fixes those warnings too (mostly with yarn lint-fix and then manually a few stragglers)

Security Considerations

--

Documentation Considerations

--

Testing Considerations

--

@turadg turadg requested a review from mhofman May 2, 2022 17:57
@turadg turadg requested a review from dtribble as a code owner May 2, 2022 17:57
@mhofman
Copy link
Member

mhofman commented May 2, 2022

I remember some problem with using object as the base type for typedefs, mostly that typescript in non strict mode considers it like any.

See microsoft/TypeScript#47694 (comment)

@turadg
Copy link
Member Author

turadg commented May 2, 2022

I remember some problem with using object as the base type for typedefs, mostly that typescript in non strict mode considers it like any.

Oh my. Indeed.

Though it appears to do the same for Object so not relevant to this change?

@mhofman
Copy link
Member

mhofman commented May 3, 2022

Though it appears to do the same for Object so not relevant to this change?

Right, Object as the base was wrong in the first place. As long as we've confirmed that there is no side-effect on tsc checks from using object, I'm ok with this change

Copy link
Member

@mhofman mhofman left a comment

Choose a reason for hiding this comment

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

I need to pay closer attention to all the changes, and do some experiments in the TS Playground.

While Object -> object should be safe for any @typedef {object} or @param {object} used as the base of other @param, I'm not certain when used as return values or in TS style functions types it'd be safe.

I agree it would be great to fix all our Object usages, as they're all most likely wrong, but I'd rather get it right than change it into another wrong. Maybe we can file an issue and pick this up after MN-1, or there was a motivation for this change now besides declared support for Node 18?

Comment on lines -23 to +25
* @param {(baseRef: string) => Object} fetch Function to retrieve an
* @param {(baseRef: string) => object} fetch Function to retrieve an
* object's raw state from the store by its baseRef
* @param {(baseRef: string, rawState: Object) => void} store Function to
* @param {(baseRef: string, rawState: object) => void} store Function to
Copy link
Member

Choose a reason for hiding this comment

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

Here is potentially a place where it'd revert back to any

Copy link
Member Author

Choose a reason for hiding this comment

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

It was already any. That's my point in the statement,

Though it appears to do the same for Object so not relevant to this change?

Object
Screen Shot 2022-05-03 at 12 19 02 PM

object
Screen Shot 2022-05-03 at 12 18 52 PM

@@ -140,7 +140,7 @@ export function makeCache(size, fetch, store) {
* of virtual references.
* @param {() => number} allocateExportID Function to allocate the next object
* export ID for the enclosing vat.
* @param { (val: Object) => string} getSlotForVal A function that returns the
* @param {(val: object) => string} getSlotForVal A function that returns the
Copy link
Member

Choose a reason for hiding this comment

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

I believe it's the same here, val would now become an any type.

Copy link
Member Author

Choose a reason for hiding this comment

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

now become an any type

Again, already was.

@turadg
Copy link
Member Author

turadg commented May 3, 2022

I need to pay closer attention to all the changes, and do some experiments in the TS Playground. …  I'd rather get it right than change it into another wrong.

What are your concerns? From what I see, all the Object are any before and after.

Maybe we can file an issue and pick this up after MN-1, or there was a motivation for this change now besides declared support for Node 18?

Yes, motivation was to update the dep to support Node 18. I thought fixing the warnings would be good to include now and safe. If you don't think so I can remove that and suppress the warnings instead. But based on…

As long as we've confirmed that there is no side-effect on tsc checks from using object, I'm ok with this change

Will you Approve so I can merge?

Copy link
Member

@mhofman mhofman left a comment

Choose a reason for hiding this comment

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

What are your concerns? From what I see, all the Object are any before and after.

I had missed that all usages of Object also resulted in any, making it strictly equivalent to object in JSDoc.

As long as we've confirmed that there is no side-effect on tsc checks from using object, I'm ok with this change

Will you Approve so I can merge?

Given that Object and object are as bad as each other in all usages, approved.

@turadg turadg added the automerge:no-update (expert!) Automatically merge without updates label May 3, 2022
@mergify mergify bot merged commit 4ce04cd into master May 3, 2022
@mergify mergify bot deleted the ta/bump-eslint-plugin-jsdoc branch May 3, 2022 20:28
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
automerge:no-update (expert!) Automatically merge without updates
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants