-
Notifications
You must be signed in to change notification settings - Fork 333
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
Various JSDoc + type checking fixes #2987
Conversation
5529e24
to
e754050
Compare
e754050
to
405710d
Compare
405710d
to
e9fc5f3
Compare
e9fc5f3
to
b753cce
Compare
b753cce
to
2271e3c
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Cheers for going through all these type checks 🙌🏻 . I'm only half way through the files, but I'm sharing my current comments in case you want to have a look.
src/govuk/components/character-count/character-count.unit.test.mjs
Outdated
Show resolved
Hide resolved
src/govuk/components/character-count/character-count.unit.test.mjs
Outdated
Show resolved
Hide resolved
2271e3c
to
835cb3c
Compare
src/govuk/components/character-count/character-count.unit.test.mjs
Outdated
Show resolved
Hide resolved
835cb3c
to
e207d11
Compare
e207d11
to
df68cdf
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've been through and taken another look for anything that might be a breaking change and can't see anything either. Let's get this merged, we can always iterate.
Thanks for all your hard work on this, @colinrotherham 🙌🏻
This allows to forward the type of the `NodeListOf` it iterates on to the parameters of the callback. In turn this should allow to drop quite a few `instanceof` checks when using the function by properly typing the `NodeList` we give it. Interesting links: - [The `@template` JSDoc tag](https://www.typescriptlang.org/docs/handbook/jsdoc-supported-types.html#template) - [How to constrain the generic type](https://stackoverflow.com/a/54631901)
Various `instanceof` additions to help the `tsc` compiler discover potential issues For example a mouse or keyboard `event.target` might not necessarily be the element we expect
I18n.pluralRulesMap keys are variable so “string” wasn’t compatible when the compiler thought we were using fixed string literals Might be worth another look at `Object.keys()` in future with: * microsoft/TypeScript#45464
Including shared file and helper functions
Thanks @romaricpascal @36degrees I'll rebase, fix the conflicts then merge 👍 Two of the commits made it into this one but I'll keep them in here since it was approved first: |
Regarding fallback value types * Preferring `null` for DOM method fallbacks * Preferring `undefined` for string fallbacks
Uses 3x handlers per component versus per tab link
Also includes: 1. Checks for `$module` on instantiation 2. Checks for selectors on init We prefer `{Element}` type to `{HTMLElement}` etc to maintain compatibility with `querySelector`
dbf3b90
to
0718c67
Compare
This is a “just in case” commit where early ES2015 class implementations would return `undefined` in a subclass constructor (extended component) rather than the subclass instance Might only affect Safari 9 See: #2987 (comment)
This is a “just in case” commit where early ES2015 class implementations would return `undefined` in a subclass constructor (extended component) rather than the subclass instance Might only affect Safari 9 See: #2987 (comment)
This is a “just in case” commit where early ES2015 class implementations would return `undefined` in a subclass constructor (extended component) rather than the subclass instance Might only affect Safari 9 See: #2987 (comment)
This PR makes a few catch-up tweaks and suggestions for our
js.md
JavaScript style guide$module
!this.$module
calling.init()
Note: Some code changes were made after setting up JavaScript Standard Style with the "type declaration support" shareable ESLint config that helped spot potential problems. We may want to enable this in future.
Linting JSDoc type declarations
We recently ensured all JSDoc comments compile correctly via
npm run build:jsdoc
(See Review app JavaScript Documentation)
Linting JSDoc type declarations spotted things like:
[param]
@param
called using previous implementations, not matching JSDoc@return
different to actual return type, JSDoc not matching usageWhich continues work we started for v4.4.0:
To assist with code reviews I've split these changes into:
@params
etc #3103