Conversation
|
Size Change: -3 B (0%) Total Size: 889 kB
ℹ️ View Unchanged
|
sirreal
commented
Mar 29, 2020
packages/element/tsconfig.json
Outdated
Comment on lines
+7
to
+8
Member
Author
There was a problem hiding this comment.
Removing these lines:
noImplicitAny-> 51 errorsstrictNullChecks-> 7 errors- both -> 60 errors
75 tasks
sirreal
force-pushed
the
try/type-wp-element
branch
from
ca897c8 to
c3549e2
Compare
sirreal
requested review from
aduth,
ajitbohra,
gziolo,
jorgefilipecosta,
nerrad,
ntwb and
youknowriad
as code owners
sirreal
added
[Package] Element
sirreal
force-pushed
the
try/type-wp-element
branch
from
7088eae to
d3fe07e
Compare
Member
Author
|
Rebased and removed commits from #20669 which has been merged. |
aduth
reviewed
Mar 31, 2020
Allow function or class components, rather than just class components.
Co-Authored-By: Andrew Duthie <andrew@andrewduthie.com>
Co-Authored-By: Andrew Duthie <andrew@andrewduthie.com>
sirreal
force-pushed
the
try/type-wp-element
branch
from
06b1bf9 to
8bed5cf
Compare
Member
Author
|
Rebased to fix conflict. Would it be possible to move forward with this? Many packages depend on |
sirreal
added
the
Needs Technical Feedback
aduth
reviewed
Apr 27, 2020
Comment on lines
-16
to
+20
| * @return {WPComponent} Dangerously-rendering component. | ||
| * @return {JSX.Element} Dangerously-rendering component. |
Member
There was a problem hiding this comment.
I wondered how this worked.
Turns out it doesn't:
[0] /home/travis/build/WordPress/gutenberg/packages/element/src/raw-html.js
[0] 20:0 warning The type 'JSX' is undefined jsdoc/no-undefined-types
https://travis-ci.com/github/WordPress/gutenberg/jobs/314225929
I thought these rules were upgraded to be errors in #20427. I think this one might have been missed? (cc @sainthkh)
I know we have a handful of temporary exceptions for custom types, but pretty sure those are hard-coded to be exceptions and could still exist even if the rule were upgraded from warning to error.
Member
Author
There was a problem hiding this comment.
Is this a concern with restoring the element types? #21781
Contributor
There was a problem hiding this comment.
It happened because I missed this one rule:
gutenberg/packages/eslint-plugin/configs/jsdoc.js
Lines 82 to 83 in 5bd92c6
I opened an issue that fixes it: #21942.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
Add types/typechecking to
@wordpress/element. Many other packages that would be extremely valuable to type, namely@wordpress/dataand@wordpress/components, depend on this package. Typing it unblocks a lot of work on other package typings.Add
unknownandneverTypeScript types to allowed JSDoc types.✅
Includes squash-merged #20669, necessary for some required types.Part of #18838
How has this been tested?
npm run build:package-typespasses.Screenshots
Types of changes
New feature: Add types
Checklist: