feat(specs): add recommend spec and client
#19
Conversation
shortcuts
force-pushed
the
feat/recommend-spec
branch
from
6df739b
to
459e628
Compare
shortcuts
requested review from
damcou and
millotp
and removed request for
damcou
✔️ Code generated!
|
| "generate": "yarn generate:js && yarn lint", | ||
| "generate:search": "yarn generate:js:search && yarn lint", | ||
| "playground:js": "yarn workspace algoliasearch-client-javascript-playground start", |
There was a problem hiding this comment.
Shouldn't we keep a playground:js command which launch every tests ?
There was a problem hiding this comment.
I made it specific to the client but if you want them grouped I don't really mind: https://github.com/algolia/api-client-automation-experiment/blob/459e6288f2784f55ce73013fb696d134e5c365c7/package.json#L27-L28
There was a problem hiding this comment.
I saw that, but it could be useful to have both (with a command which launch playground:js:* )
shortcuts
force-pushed
the
feat/recommend-spec
branch
from
36749c2
to
7f9c932
Compare
|
Unused import in this PR will be removed once |
| "utils:import-js": "mkdir -p -- clients/algoliasearch-client-javascript/utils && cp -R clients/utils/javascript/ clients/algoliasearch-client-javascript/utils" | ||
| "playground:js:search": "yarn workspace javascript-playground start:search", | ||
| "playground:js:recommend": "yarn workspace javascript-playground start:recommend", | ||
| "utils:import-js": "mkdir -p -- clients/algoliasearch-client-javascript/${CLIENT}/utils && cp -R clients/algoliasearch-client-javascript/utils/ clients/algoliasearch-client-javascript/${CLIENT}/utils" |
There was a problem hiding this comment.
If we go on the same package style as the original client, instead of copying multiples times utils I think we should make a package-utils, wdyt ?
There was a problem hiding this comment.
definitely, we still need to improve the tooling on this side
Summary
recommendclient and specalgoliasearch-client-javascriptrepository402error when feature is not availableDisclaimer
Types
Same as #17, "complex" types are weirdly generated.
If we decide to go with a more optimal yml (avoid rewriting same parameters, like I tried on both PRs), some types are exported/not used etc. but when we duplicate the content in the yml, the output is better.
Ref
openapi-generatorstruggle with relative paths, which requires us to rewrite some logic like: https://github.com/algolia/api-client-automation-experiment/blob/429b1ba524d4a44182402eda26e7d66332fca03d/specs/recommend/paths/getRecommendations.yml#L35-L42(and also create useless types).
Next
package.json, I guess it's a good time to focus on scripts :D