feat(cli): Add inline property to type references from properties in Fern definition with OpenAPI importer

[Swimburger]

Description

In the Fern definition, you can express your desire to inline a type from a property on a type or request:

service:
  endpoints:
    endpointName:
      ...
      request:
        ...
        body:
          ...
          properties:
            bar:
              type: InlineType

types:
  RootType:
    properties:
      bar:
        type: InlineType
  InlineType:
    inline: true
    properties:
      ...

The IR generated from this Fern definition will store the desire to inline a type on the type declaration.

Changes Made

• Update Fern definition to allow inline true on declarations
• Update OpenAPI parser and OpenAPI IR to pass inline to the generated Fern definition
• Update Fern to IR generator to pass on inline to types

Testing

• Unit tests added/updated

Added more test definitions + evaluate existing test definition snapshots.

[github-actions]

🌿 Preview your docs: https://fern-preview-88961635-e79c-40f8-ae9e-10c6827008c0.docs.buildwithfern.com/learn

[dsinghvi]

i assume this is the only thing that changed? nit: would be nice to remove the formatting changes for this PR

[dsinghvi]

Do you need this property? If a SchemaWithExample contains another SchemaWithExample that is not a reference, you already know the type is inlined

[dsinghvi]

In other words, in openapi-ir-to-fern when you call buildTypeDeclaration() and then that calls buildTypeReference and that calls buildTypeDeclaration again, you know that the second declaration call is for an inlined type.

[dsinghvi]

So if we just tracked depth of call, then i think we should be able to control inline based on that

[amckinney]

Looks good to me - only a couple comments worth considering before merging!

[amckinney]

Should WithInline just be part of BaseTypeDeclarationSchema? It looks like we omitted it from AliasSchema which is reasonable, but it's theoretically possible that we generate an alias with a bad name too, and we could just as easily create an in-lined alias type.

That way any TypeDeclaration moving forward will always be able to be in-lined. Curious to hear your thoughts though - I realize this case is less important overall.

[amckinney]

It might be worth leaving a function-level comment on this one - I could see us forgetting the rationale around how we're detecting whether or not a type is in-lined. It looks like this was inspired by this comment?