-
Notifications
You must be signed in to change notification settings - Fork 725
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Refactored type definitions #1119
Conversation
- Removed old test code - Added tsd dev dependency - Rewritten test with tsd
This is sooo good. Thank you so much for the hard work :-) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I tried to run node scripts/generate --tag=v7.6.1
but it didn't finish after 30 min. Are there any specific setup requirements to run the command locally?
scripts/utils/generateMain.js
Outdated
return methods | ||
} else { | ||
let methods = [ | ||
{ key: `${api}<B = any, C = any> ()`, val: `Promise<ApiResponse<B, C>>` }, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there a difference in output between this and https://github.com/elastic/elasticsearch-js/pull/1119/files#diff-a2dd684ce54a1e12240718626f065766R200 ? Probably we can merge them and always use { key:
${camelify(api)}<B = any, C = any> (), val:
Promise<ApiResponse<B, C>> },
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The client supports both snaked_cased apis and camelCased apis, for instance the latest async search will be available both as async_search
and asyncSearch
.
That if check only verifies if we should or not generate the camelCased api as well.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
just to confirm: not all snake_case
API methods have camelCase
counterparts?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
All snake_case
API methods have a camelCase
counterpart :)
Nope, it should just work. Did it log something? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I fear there is a bug and the very first run of the code generation should use master, I've just run in a freshly cloned repo
Now it works, great!
Thank you for starting this effort 🚢
- Use extends for defining the RequestBody generic to force the user following the same shape. - BodyType and NDBodyType now accepts a generics to allow injecting more specific types in the future
I did another change, hopefully, the last one! search<RequestBody = BodyType, Response = any, Context = unknown>(params: RequestParams.Search<RequestBody>, options: TransportRequestOptions): Promise<ApiResponse<Response, Context>> Which worked well if the user was passing their own types, but if they were using the defaults, ts didn't "followed" the // note that number is not present in BodyType
client.search({ index: 'test', body: 42 }) For addressing this issue, now we are using search<RequestBody extends BodyType, Response = any, Context = unknown>(params: RequestParams.Search<RequestBody>, options: TransportRequestOptions): Promise<ApiResponse<Response, Context>> And as result the following code is no longer valid. client.search({ index: 'test', body: 42 }) Furthermore, I've used Finally, search<RequestBody extends BodyType<SearchBody>, Response = BodyType<SearchResponse>, Context = unknown>(params: RequestParams.Search<RequestBody>, options: TransportRequestOptions): Promise<ApiResponse<Response, Context>> I fear we should accept the fact that we could release breaking changes for the type definitions in minors, as ts is a rapidly evolving language and they are releasing breaking changes in minors as well. |
- prefixed all generics with a T - BodyType => RequestBody - NDBodyType => RequestNDBody - Added ResponseBody
The backport to
To backport manually, run these commands in your terminal: # Fetch latest updates from GitHub
git fetch
# Create a new working tree
git worktree add .worktrees/backport-7.x 7.x
# Navigate to the new working tree
cd .worktrees/backport-7.x
# Create a new branch
git switch --create backport-1119-to-7.x
# Cherry-pick the merged commit of this pull request and resolve the conflicts
git cherry-pick 6c82a4967ea5bed2370f9279226b59588b0a5950
# Push it to GitHub
git push --set-upstream origin backport-1119-to-7.x
# Go back to the original working tree
cd ../..
# Delete the working tree
git worktree remove .worktrees/backport-7.x Then, create a pull request where the |
* Updated types generation script * Refactored api method definitions * Updated test - Removed old test code - Added tsd dev dependency - Rewritten test with tsd * Removed unused dependencies * Fixed definition * Updated test * Updated docs * Improved events type definitions * Updated test * Minor fixes in the type definitons * More type test * Improved Transport type definitions * Updated test * Addressed comments * Code generation * Use RequestBody, Response and Context everywhere, also default Context to unknown * Updated test * body -> hasBody * Fixed conflicts * Updated code generation * Improved request body type definition * Updated code generation * Use BodyType for both request and reponses generics - Use extends for defining the RequestBody generic to force the user following the same shape. - BodyType and NDBodyType now accepts a generics to allow injecting more specific types in the future * API generation * Updated test * Updated docs * Use BodyType also in ReponseError * Removed useless client generics * Renamed generics and types - prefixed all generics with a T - BodyType => RequestBody - NDBodyType => RequestNDBody - Added ResponseBody * Updated test * Updated docs * Test ResponseBody as well * Simplify overloads * API generation * Updated test * Updated error types
This pr improves massively our type definitions, the best way to explain how, is to show it:
Old definitions (example taken from the old documentation):
New definitions (example taken from the new test):
TL;DR
Now every API makes better use of the generics and overloading, so you can (or not, by default request/response bodies are
any
) define the request/response bodies in the generics.This should not be a breaking change, as every generics defaults to
any
. It might happen to some users that the code breaks, but our test didn't detect any of it, probably because they were not robust enough. However, given the gigantic improvement in the developer experience, we have decided to release this change in the 7.x line.This pr also introduces a vastly improved testing infrastructure for addressing the old fragile tests.
This pr should also help the future work we will do to address #933.
Don't get scared by the size of the pr, most of the code (in
index.d.ts
) is generated from a script, once you have reviewed a few lines, you have reviewed them all! ;)Thank you to @fox1t for helping me designing this!