mirror of
https://github.com/elastic/kibana.git
synced 2025-04-23 17:28:26 -04:00
correct relativity in images (#113834)
This commit is contained in:
parent
a565fa02f3
commit
6f665004cb
1 changed files with 3 additions and 3 deletions
|
@ -111,7 +111,7 @@ export getSearchService: (searchSpec: { username: string; password: string }) =>
|
|||
|
||||
In the former, there will be a link to the `SearchSpec` interface with documentation for the `username` and `password` properties. In the latter the object will render inline, without comments:
|
||||
|
||||

|
||||

|
||||
|
||||
#### Export every type used in a public API
|
||||
|
||||
|
@ -135,7 +135,7 @@ export type foo: string | AnInterface;
|
|||
|
||||
`Pick` not only ends up being unhelpful in our documentation system, but it's also of limited help in your IDE. For that reason, avoid `Pick` and other similarly complex types on your public API items. Using these semantics internally is fine.
|
||||
|
||||

|
||||

|
||||
|
||||
### Example plugins
|
||||
|
||||
|
@ -210,7 +210,7 @@ your large change right _after_ feature freeze. If you are worried about missing
|
|||
|
||||
When possible, build features with incrementals sets of small and focused PRs, but don't check in unused code, and don't expose any feature on master that you would not be comfortable releasing.
|
||||
|
||||

|
||||

|
||||
|
||||
If your feature cannot be broken down into smaller components, or multiple engineers will be contributing, you have a few other options to consider.
|
||||
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue