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
[STRIPES-859] Re-export type declarations from stripes-types #208
Conversation
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 sort out why GitHub can't resolve @folio/stripes-types
, and decide where @types/react
belongs in our dependency hierarchy for this can be merged.
@zburke would we be able to get this merged soon? I'd like to start using these typings in |
@JohnC-80 / @zburke thanks for the reviews; I think there's only one thing left before this can get merged then: React typings are provided by a package |
Merged #211 instead |
Jira STRIPES-859
This PR adds
index.d.ts
files to re-export types stored instripes-types
. Initially, this consists of typings forstripes-components
,stripes-core
,stripes-final-form
, andstripes-smart-components
— all other modules will have no associated type information, as it was previously.For convenience, here is a link to stripes-types.
What is in
stripes-types
so far?For modules
stripes-components
,stripes-core
, andstripes-smart-components
, all declarations are denoted asany
, disabling type checking and having no effect, e.g.:All exports from the original modules'
index.js
files are included here.stripes-final-form
is the exception to this; since it only has one export, we have created actual type definitions for the stripesFinalForm function.What effect will this PR have?
First off, this will only affect TypeScript modules. Modules which do not use TS will not use the TS compiler and thus these type declaration files are irrelevant.
There are (as far as I know) only two modules which use TypeScript:
ui-calendar
andui-bulk-edit
, both of which contain their own type declarations for these modules (calendar, bulk-edit) which take precedence over any we specify here. Therefore, we can safely develop these types without breaking any builds; these will only be relied upon downstream once the overridden definitions are removed (which will happen after this PR is merged and additional type development).@zburke @JohnC-80 if you would please review this when you're able!