I'd like to make a property visible for openapi but hidden to a custom emitter - how would I do that?

[Kieranties]

I am currently building a custom emitter that allows me to generate AWS lambda entry points. A key scenario is that the the lambda requires details from an authorizer which runs on the api gateway. The authorizer requires a header in the request, but the results of the authorizer are in the authorizer context which is sent to the lambda.

So the sequence looks like this:

1. Request is sent with header my-custom-header
2. Gateway passes request to authorizer
3. Authorizer processes request and returns my-result
4. Gateway adds my-result to lambda payload
5. Lambda receives payload

In my custom emitted code I am rendering a function which receives each parameter required for the lambda. In this case, my-custom-header should not be received by the lambda, but my-result should. On the generated openapi my-result should not be exposed, but my-custom-header should.

I currently have two decorators

• lambdaAuth - this sets visibility to the string value lambda preventing the property from appearing in the openapi. It also marks the property to be resolved from the authorizer context when emitting the lambda code.
• lambdaIgnore - this prevents a property from being emitted to the lambda.

Example

This works well for the custom lambda, but not so well for the openapi. The following is a trivial example

Define the model of the operation

model LambdaRequest {
    @lambdaIgnore
    @header("my-custom-header")
    openapiOnly: string;

    @lambdaAuth("my-result")
    lambdaOnly: string;
}

Define the operation

@route("/get")
op getMany(...LambdaRequest): OkResponse;

In the generated openapi spec my request is a post with an empty object

The same issue occurs if I directly add the members or use the spread operator.

Is there a better approach to this, or is this a bug being uncovered?

[timotheeguerin]

Hi @Kieranties that's awesome to hear you trying to write an emitter for typespec!

For your question it is a good one, we think your approach is a correct way of representing it, we talked a little bit with the team and sounds like we have probably a bug/some change to do in the http library regarding that body resolution. I filed an issue for that part #2513

Taking a step back however:
Is that header combo always the same? At least the lambda converted name? Could that name be automatically resolved by the emitter, I feel like that if you require user to do that it might be quite error prone. That could probably be mitigated with some template model that you spread to get those properties but I think this is something to make sure to think about if people are not very careful will they have a non functioning lambda.

[Kieranties]

Huge thanks for the feedback and validation. Writing the emitter has been a good challenge to flex in a new space for me. And it's been working great!

Your response on spreading the model is spot on. That's exactly what I have set up. This was a contrived example, but I have an authoriser project that creates a lambda and a typespec package that models its request requirements.

Other lambdas then consume the package and add the model to their operation by spreading it in, or extending