# using SpeakeasyBar;`,

    },
    {
      label: "Unity",
      language: "yaml",
      code: `# For Unity to configure global imports, the \`imports\` section
  # of your \`gen.yaml\` needs to include the following:

  unity:
    ...
    imports:
      option: openapi
      paths:
        callbacks: Models
        errors: Models
        operations: Models
        shared: Models
        webhooks: Models

  # OR

  unity:
    ...
    imports:
      option: openapi
      paths:
        callbacks: ""
        errors: ""
        operations: ""
        shared: ""
        webhooks: ""

  # For global imports in Unity, models will always be generated to the
  # \`Models\` directory, regardless of whether the \`""\` or \`"Models"\`
  # path is specified. However, global imports will only kick in if one of
  # these two values is used for all buckets. This is to ensure the root
  # directory isn't cluttered with files.

  # The configuration example above will result in a directory structure
  # like this:
  /
  ├─ {{packageName}}/
  │  ├─ Models/
  │  │  ├─ User.cs
  │  │  ├─ Drink.cs
  │  │  ├─ GetUserRequest.cs
  │  │  ├─ GetUserResponse.cs
  │  │  ├─ UpdateUserRequest.cs
  │  │  ├─ UpdateUserResponse.cs
  │  │  ├─ GetDrinkRequest.cs
  │  │  ├─ GetDrinkResponse.cs
  │  │  ├─ UpdateDrinkRequest.cs
  │  │  ├─ UpdateDrinkResponse.cs
  │  │  ├─ SDKError.cs
  │  │  ├─ ResponseError.cs
  │  │  └─ ...
  │  └─ ...
  └─ ...

  # As all the models will be under the root namespace of the SDK, 
  # import models like so:
  # using SpeakeasyBar;`,
}
]}
/>

<Callout title="Caution" type="warning">
Global imports will cause namespace pollution for the import and file clutter in the directory models are generated to. 
<br />
Large APIs containing many models (especially many inline models) will inevitably lead to name conflicts. Rename types verbosely to ensure each class is unique within the namespace.
</Callout>