-
Notifications
You must be signed in to change notification settings - Fork 470
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
feat: migrate some files to typescript #848
feat: migrate some files to typescript #848
Conversation
This pull request is automatically built and testable in CodeSandbox. To see build info of the built libraries, click here or the icon next to each commit SHA. Latest deployment of this branch, based on commit d15238b:
|
Codecov Report
@@ Coverage Diff @@
## master #848 +/- ##
=========================================
Coverage 100.00% 100.00%
=========================================
Files 26 26
Lines 941 945 +4
Branches 289 290 +1
=========================================
+ Hits 941 945 +4
Continue to review full report at Codecov.
|
d3ce72c
to
8c82991
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.
Very cool @marcosvega91 👏
src/__tests__/config.js
Outdated
@@ -1,4 +1,4 @@ | |||
import {configure, getConfig} from '../config' | |||
import {configure, getConfig} from '../config.ts' |
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.
Interesting. Is the extension required? I didn't think it was and would prefer to not have to specify it.
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 don't like too, but I didn't find a way to not specify it. eslint
gave me some trouble.
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.
We can deal with that later. Not a ship stopper.
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'll leave the point open, maybe someone could help
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.
We need to remember that the types
directory should be completely removed when this migration is finished. There's no reason to keep it around once we can generate the types from the source.
But for now, this is perfect 👍
Personally, I think let's get this merged, then we can continue to iterate and avoid large branches. |
I have only one more file |
ready for now |
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.
Looking good to me. I don't plan to merge this myself, but I did leave a few thoughts and ideas that aren't a big deal either way.
src/label-helpers.ts
Outdated
} else if ('value' in node) { | ||
textContent = node.value |
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.
} else if ('value' in node) { | |
textContent = node.value |
src/label-helpers.ts
Outdated
} else { | ||
textContent = node.value || node.textContent | ||
textContent = node.textContent |
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.
Could this work?
textContent = node.textContent | |
textContent = node?.value ?? node.textContent |
Or even
textContent = node.textContent | |
textContent = node.value ?? node.textContent |
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.
The problem here is that node can't be null but at the same time only input has value.
So doing node?.value
is not correct because node is not nulla and node.value
is not correct because input doesn't have a value
src/label-helpers.ts
Outdated
function getRealLabels(element) { | ||
if (element.labels !== undefined) return element.labels ?? [] | ||
function getRealLabels(element: Element | HTMLInputElement) { | ||
// for old browsers | ||
// eslint-disable-next-line @typescript-eslint/no-unnecessary-condition | ||
if ('labels' in element && element.labels !== undefined) | ||
return element.labels ?? [] |
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 would prefer we don't change any runtime behavior but rather override the typechecker with type-casting or @ts-expect-error
. Right now I can't know from the review whether this changes runtime behavior, or was unsound, or just TS being overly strict.
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.
The problem here is the labels can be null and not undefined. Btw I think that on old browser like ie labels is undefined and not null
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.
Looks to me covered all these cases and TypeScript is not able to narrow. Let's keep the runtime and annotate the compile time properly.
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.
The problem is that the linter is giving the problem, so @ts-expect-error
will not work
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.
Ignore the linter.
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.
Proposed follow-up in marcosvega91#2
Should have the minimal set of runtime changes. Kept the switch from match
to test
which could be merged regardless of types.
Forgot to update the PR title of the recently merged #821. Changing this PR to a feature (can always do that) so that we can kick of a release. |
thanks for the help @eps1lon :) |
"extends": "./node_modules/kcd-scripts/eslint.js", | ||
"extends": [ | ||
"./node_modules/kcd-scripts/eslint.js", | ||
"plugin:import/typescript" | ||
], |
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.
As recommended: https://github.com/benmosher/eslint-plugin-import#typescript
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.
Yes I see, the strange thing is that is should already be in kcd
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.
It should be. That's an oversight
🎉 This PR is included in version 7.29.0 🎉 The release is available on:
Your semantic-release bot 📦🚀 |
follow-up #614
I have started migrating @testing-library/dom to typescript. The idea is also to complete step by step PR #834
Types are not generated until everything is completed
Any suggestions and advice are always welcome 🙏🏽
I want to add more files to this PR.
What: File migrated
Why: Is cool and fun
How:
Checklist:
docs site