Conversation
There was a problem hiding this comment.
Removed as we're using import { METRIC_TYPE } from '@kbn/analytics' everywhere except in lens and the data plugins (which I changed in this PR).
There was a problem hiding this comment.
I'm normalizing this import to how it's done everywhere else. This way we can avoid re-exporting it from the usageCollection plugin 😇
f4b4285 to
e5227cc
Compare
There was a problem hiding this comment.
Normalizing this import so we don't need to re-export it from the usageCollection plugin
e5227cc to
aa2bcad
Compare
aa2bcad to
df43089
Compare
|
|
||
| export class NestedInside { | ||
| collector?: UsageCollector<Usage>; | ||
| collector?: Collector<Usage>; |
There was a problem hiding this comment.
Using Collector as a general interface. Not exporting UsageCollector anymore. This will help in the future when/if we want to merge both entities back into one.
|
Pinging @elastic/kibana-core (Team:Core) |
|
Pinging @elastic/kibana-telemetry (Team:KibanaTelemetry) |
e846e3d to
fedf20b
Compare
flash1293
left a comment
There was a problem hiding this comment.
Lens changes LGTM - great simplification!
Dosant
left a comment
There was a problem hiding this comment.
app services code changes lgtm
| export interface ICollectorOptionsFetchExtendedContext<WithKibanaRequest extends boolean> { | ||
| /** | ||
| * Set to `true` if your `fetch` method requires the `KibanaRequest` object to be added in its context {@link CollectorFetchContextWithRequest}. | ||
| * @remark You should fully understand acknowledge that by using the `KibanaRequest` in your collector, you need to ensure it should specially work without it because it won't be provided when building the telemetry payload actually sent to the remote telemetry service. |
There was a problem hiding this comment.
NIT: You should fully understand acknowledge
| * Unique string identifier for the collector | ||
| */ | ||
| type: string; | ||
| init?: Function; |
There was a problem hiding this comment.
Any way to be more specific than Function?
There was a problem hiding this comment.
I'm actually wondering if we could remove it (I believe this API is not used at all since it was never documented). I'll see if that statement is true :)
💚 Build Succeeded
Metrics [docs]Public APIs missing comments
Async chunks
Public APIs missing exports
Page load bundle
History
To update your PR or re-run it, just comment with: |
💔 Backport failed
To backport manually run: |
# Conflicts: # api_docs/usage_collection.json # api_docs/usage_collection.mdx
|
Backport to |
Summary
This PR cleans up all the unused APIs exposed by the
usageCollectionplugin and documents the exposed ones.When running
node scripts/build_api_docs --plugin usageCollection --stats any --stats comments --stats exportswe still get the following warnings.This is because the current tool is not able to link the JSDocs and the methods declared as
const myFn = (prop) => arrowFnResult. (#98744)Also, reNevermind, I found out it's because I was addingSerializeCounterParams, it is exposed. I may need some help from @stacey-gammon to find out what is it that I'm missing 🥺@internalto that interface's docs.Checklist
For maintainers