Component types export

[xfournet]

Description

Export the TS type in api/_types to Types

Issues Resolved

Closes #955

Check List

• New functionality includes testing -> I didn't see tests for generator
• All tests pass
• Linter check was successfull - yarn run lint doesn't show any errors
• Commits are signed per the DCO using --signoff
• Changelog was updated.

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

[nhtruong]

Looks great! There's a type error in CI tho. You will have to run the generator and commit the changes from the generator as well.

I'm manually triggering the api_gen workflow so that your PR will only contain the changes from the new type module. Don't forget to rebase.

[xfournet]

Looks great! There's a type error in CI tho. You will have to run the generator and commit the changes from the generator as well.

I'm manually triggering the api_gen workflow so that your PR will only contain the changes from the new type module. Don't forget to rebase.

The type error is because i didn't commit the ouput of the generator so far :) you should trigger the api_gen workflow first ?

[xfournet]

I get a lot of unrelated diff (same result without my change).
Do I need to use a precise version of the opensearch-openapi.yaml or use the latest anyway ? in the later case i will separate the 'update to latest spec' commit from the others

[nhtruong]

The spec repo gets updated very frequently. So every time you download the latest spec, there will be other API changes to the client. It's okay to have some in your PR. We need to see what the new generated Types module will look like and if it causes any type error for this PR.

I'll trigger the generator at the end of the day so that when you download and the run the generator for this PR, there will be very few unrelated changes.

[xfournet]

@nhtruong my bad i didn't understand you committed the update on the main branch. Since the spec have change again :( wouldn't be better to commit the downloaded opensearch-openapi.yaml (or commit a 'frozen' link if possible ?) so it's clear which version has been used for the generation ?

[nhtruong]

wouldn't be better to commit the downloaded opensearch-openapi.yaml (or commit a 'frozen' link if possible ?) so it's clear which version has been used for the generation ?

That's a great idea. @dblock What do you think? I remember us discussing versioning the spec itself once it's stabilized and save the commit hash that's used to generated the client. Maybe we can just save the spec file itself in each repo for now till we have versioned spec?

[dblock]

wouldn't be better to commit the downloaded opensearch-openapi.yaml (or commit a 'frozen' link if possible ?) so it's clear which version has been used for the generation ?

That's a great idea. @dblock What do you think? I remember us discussing versioning the spec itself once it's stabilized and save the commit hash that's used to generated the client. Maybe we can just save the spec file itself in each repo for now till we have versioned spec?

we have releases of the spec, https://github.com/opensearch-project/opensearch-api-specification/releases, feel free to release 0.2.0

[xfournet]

In meantime i was able to retrieve the version used for the last generation (https://github.com/opensearch-project/opensearch-api-specification/actions/runs/12698838181)
The PR is up to date

[nhtruong]

Does this mean to use QueryContainer:

import type { Types } from '@opensearch-project/opensearch';
const query: Types.Common_QueryDsl.QueryContainer = { ... }

What if you know it's QueryContainer but doesn't know which sub module it belongs to? Would the IDE be able to provide autocomplete if you just type QueryContainer. What about something like Types.Common_QueryDsl_QueryContainer?

[xfournet]

Yes, it's necessary to have the Common_QueryDsl 'prefix' since there are many names that collides across the different files.
I'm not sure that aggregating the prefix and the interface name have an advantage over this approach, but i can change that if needed (PS the generated index file will be much larger that currently)

[nhtruong]

That's what the API index file is doing. But I guess if the user doesn't know where the type is located, they can always use NonNullable<API.UpdateByQuery_Request['body']>['query']