export Result Definition types

[dtwiers]

I'd like to use these to define common functions for providesTags in my client code

[codesandbox-ci]

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 ddfb3b2:

Sandbox	Source
Vanilla	Configuration
Vanilla Typescript	Configuration
rsk-github-issues-example	Configuration

[netlify]

Deploy preview for redux-starter-kit-docs ready!

Built with commit ddfb3b2

https://deploy-preview-1022--redux-starter-kit-docs.netlify.app

[Shrugsy]

Unless I'm mistaken, these will need to be added to the exports in src/query/index.ts as well to actually import them from outside of the library

[phryneas]

Yes and no. If we no longer go for a single-type-file-rollup, they can just be imported manually from dist/ts, which I would prefer for a lot of those types as they're still "kinda internal" (this one is more public, but doesn't feel "important enough" to be exported by index? I don't know 🤔 )

We should probably go through all exports everywhere and mark them as @public or @internal to mark a "stable API interface" and other types as "internal type, you can use it but we might change it".

[dtwiers]

Hmm. My opinion, recognizing that I'm also not the maintainer - not usually a big fan of importing things specifying the dist folder if it's avoidable, though that's probably just my nature trying to avoid using unstable internal interfaces as a general rule. I can annotate with @internal and/or I can add it to index to re-export. What would you prefer? @Shrugsy @phryneas

[phryneas]

I'll merge this in now and we'll discuss that along the way. Thanks for the contribution!