[STRIPES-859] Re-export type declarations from stripes-types #208
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.
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!