Skip to content

Conversation

@chiawendt
Copy link
Contributor

No description provided.

Copy link
Member

@ljharb ljharb left a comment

Choose a reason for hiding this comment

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

These fixes are fine, but is there some way we could use CI to ensure they stay correct? otherwise i'm not sure they're adding value.

@chiawendt
Copy link
Contributor Author

This errors are found by typescript's --checkJs feature. It pull types from jsdoc and typecheck. It is great. CI can be setup by running tsc.

@ljharb
Copy link
Member

ljharb commented May 10, 2019

Let's add an npm run-script for that, then, and a separate travis.yml job that does it, and the appropriate dev deps.

@chiawendt chiawendt force-pushed the fix-some-jsdoc-errors branch from b189e12 to 084c678 Compare May 11, 2019 11:06
@chiawendt chiawendt changed the title [Chore]: fix some jsdoc errors Build: add type check using typescript --checkJs May 11, 2019
@chiawendt chiawendt force-pushed the fix-some-jsdoc-errors branch from 084c678 to d344dca Compare May 11, 2019 11:11
/* Strict Type-Checking Options */
// "strict": true, /* Enable all strict type-checking options. */
// "noImplicitAny": false, /* Raise error on expressions and declarations with an implied 'any' type. */
// "strictNullChecks": true, /* Enable strict null checks. */
Copy link
Contributor Author

Choose a reason for hiding this comment

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

The flag strictNullChecks is left unenabled because there is about 20 places where I need to either use @ts-ignore or write very awkward codes.

@chiawendt
Copy link
Contributor Author

It might make sense to add eslint-plugin-jsdoc. The errors it catches includes: 1. Missing or superfluous jsdoc param. 2. Unmatched Jsdoc param name and actual name. 3. Enforce presence of types annotation.

*/
'use strict';

/** @type {any[]}} */
Copy link
Member

Choose a reason for hiding this comment

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

string[]?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Tsc does not accept string[]. The official type declaration requires that in a.concat(b), a and b must have the same type.

Copy link
Member

Choose a reason for hiding this comment

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

when is this array concatted with something that's not also a string[]?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

In lines bellow it is concatted with setting.something.

Copy link
Member

Choose a reason for hiding this comment

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

which should be a string[] per the schema, no?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

By schema it could be {name: something, linkAttribute: something}[]

Copy link
Member

Choose a reason for hiding this comment

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

ah - then should the type be (string | { name: string, linkAttribute: string })[]?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

But settings.linkComponents is not validated, it could be anything.

Copy link
Member

Choose a reason for hiding this comment

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

if it's not that schema tho, the plugin won't work properly, so i think we can assume that's its type.

UnionTypeAnnotation: function(annotation, parentName, seen) {
const unionTypeDefinition = {
type: 'union',
/** @type {any} */
Copy link
Member

Choose a reason for hiding this comment

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

lets avoid any use of any :-)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Tsc does not accept any[] and any[]|true.

Copy link
Member

Choose a reason for hiding this comment

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

unknown[]? unknown[] | true? you can certainly do any of those in TS, altho maybe not in jsdoc.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Tsc does not accept unknown[] unknown[]|true also.

Copy link
Member

Choose a reason for hiding this comment

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

just in jsdoc? it certainly works in TS.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

unionTypeDefinition.children is at a time assigned true, so it cannot be unknown[]. unionTypeDefinition.children.length is used, so it cannot be unknown[]|true.

Copy link
Member

Choose a reason for hiding this comment

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

then that implies there's a bug, or else type narrowing would have removed true prior to the .length access?

@chiawendt chiawendt closed this May 12, 2019
@chiawendt chiawendt force-pushed the fix-some-jsdoc-errors branch from 084c678 to fce69eb Compare May 12, 2019 09:21
@chiawendt
Copy link
Contributor Author

chiawendt commented May 12, 2019

I somehow closed this by accident. Apologies.

@chiawendt chiawendt reopened this May 12, 2019
Copy link
Member

@ljharb ljharb left a comment

Choose a reason for hiding this comment

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

I've explicitly commented on all non-comment changes, just to be thorough.

I'd still like to avoid any use of any.

LGTM pending https://github.com/yannickcr/eslint-plugin-react/pull/2267/files#r283097857

}
if (classComponent) {
handleClassUsage(node, classComponent);
handleClassUsage(node);
Copy link
Member

Choose a reason for hiding this comment

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

This is a harmless extra arg being passed - good to clean up. semver-patch.

return SVGDOM_ATTRIBUTE_NAMES[name];
}
let i;
let i = -1;
Copy link
Member

Choose a reason for hiding this comment

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

This seems to be useless, but I assume tells tsc what the type of i is. It could also be set to 0, but -1 is clearer semantically.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

If i is not initialized, it could potentially be undefined, that would make tsc reject DOM_PROPERTY_NAMES[i].

Copy link
Member

Choose a reason for hiding this comment

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

[undefined] on an object without that property is safely undefined, that's just the type system being overly strict :-)

const name = classProperties.find(propertyName => {
if (propertiesToCheck[propertyName](node)) {
return propertyName;
return !!propertyName;
Copy link
Member

Choose a reason for hiding this comment

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

Assuming the return value of reportNodeIncorrectlyPositioned is always used in a truthy/falsy position, this just returns true instead of "truthy"…

}

return null;
return false;
Copy link
Member

Choose a reason for hiding this comment

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

and false instead of "falsy".

@chiawendt
Copy link
Contributor Author

Thanks for the thorough review!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

2 participants