Fix re-exporting types from data plugin. #35682
Conversation
lukeelmers
added
:AppArch
Feature:Data Views
|
Pinging @elastic/kibana-app-arch |
💚 Build Succeeded |
lukeelmers
added
release_note:skip
| } | ||
|
|
||
| /** @public types */ | ||
| export { IndexPattern, StaticIndexPattern, StaticIndexPatternField, Field } from './index_patterns'; |
There was a problem hiding this comment.
Is this export pattern to be use only here or for all the sub-components as well?
There was a problem hiding this comment.
I did it here because the guidance from the Core team was to export all types at the top level (so downstream user's don't need to know about the paths to the subcomponents of your plugin). I suppose we could use a similar pattern at the service-level if we wanted to, the only reason I didn't was because of .d.ts files: it felt cleaner to only re-export types from the service.
In a service class file, if I were to export { Foo } from 'ui/foo'; and Foo is both a type and a module, I'll be exporting both from my service. But if I explicitly import * as types from 'ui/foo'; and export type Foo = types.Foo; it ensures that only the type is being exported.
Related: There was discussion of potentially namespacing types by service in Core (e.g. IndexPatterns.Field), but they haven't done this yet because the current thinking is that, over time, most types people will need to import will already be included in a plugin's Setup interface (DataSetup).
So my current proposed conventions for handling types during migration would be:
- Export the
setupinterface from each service (&index.ts), either usingReturnTypeor by explicitly writing the interface - Import everything into the top-level Plugin service
- Explicitly export the top-level
setupinterface (DataSetup) - Re-export any additional types for services from the top-level
This makes it so that the only place people need to import from is the top-level directory plugins/data
|
Closing as I believe these changes have already merged in another PR. |
This resolves an issue originally identified in #35300, where CI would fail due to an attempted import from a
.d.tsfile. It updates index patterns in the data plugin with a new convention for re-exporting types, which shouldn't cause CI troubles.Once this is merged it will unblock #35389, #35390, and #35460.