Order of generated paths in OpenAPI spec

[Devon-White]

I'm looking to see if there is a solution to changing the order in which paths are generated in a OpenAPI spec.

Example can be found here

In the example, you will notice that any subscriber endpoint that has a path parameter will create a new route appending the {id} (as it should) - but its not adding it directly under the route that this is declared in. You will notice that its actually being generated at the very bottom.

This looks like the following (take notice of where /resources/subscribers is and where /resources/subscribers/{id} is):

paths:
  /resources/subscribers:
    get:
      operationId: Subscribers_list
      summary: List Subscribers
      parameters: []
      responses:
        '200':
          description: The request has succeeded.
          content:
            application/json:
              schema:
                type: array
                items:
                  type: object
      tags:
        - Subscribers
    post:
      operationId: Subscribers_create
      summary: Create Subscriber
      parameters: []
      responses:
        '201':
          description: The request has succeeded and a new resource has been created as a result.
          content:
            application/json:
              schema:
                type: object
      tags:
        - Subscribers
      requestBody:
        required: true
        content:
          application/json:
            schema:
              type: object
  /resources/subscribers/{fabric_subscriber_id}/sip_endpoints:
    get:
      operationId: SubscriberSipEndpoint_list
      summary: List Subscriber SIP Endpoints
      description: A list of Sip Endpoints of the Subscriber
      parameters:
        - name: fabric_subscriber_id
          in: path
          required: true
          schema:
            type: string
      responses:
        '204':
          description: 'There is no content to send for this request, but the headers may be useful. '
      tags:
        - Subscribers
    post:
      operationId: SubscriberSipEndpoint_create
      summary: Create Subscriber SIP Endpoint
      description: Creates a Subscriber Sip Endpoint
      parameters:
        - name: fabric_subscriber_id
          in: path
          required: true
          schema:
            type: string
      responses:
        '201':
          description: The request has succeeded and a new resource has been created as a result.
          content:
            application/json:
              schema:
                type: object
      tags:
        - Subscribers
      requestBody:
        required: true
        content:
          application/json:
            schema:
              type: object
    delete:
      operationId: SubscriberSipEndpoint_delete
      summary: Delete Subscriber SIP Endpoint
      description: Deletes a Subscriber Sip Endpoint by ID
      parameters:
        - name: fabric_subscriber_id
          in: path
          required: true
          schema:
            type: string
      responses:
        '204':
          description: 'There is no content to send for this request, but the headers may be useful. '
      tags:
        - Subscribers
  /resources/subscribers/{fabric_subscriber_id}/sip_endpoints/{id}:
    get:
      operationId: SubscriberSipEndpoint_read
      summary: Get Subscriber SIP Endpoint
      description: Returns a Subscriber Sip Endpoint by ID
      parameters:
        - name: id
          in: path
          required: true
          schema:
            type: string
        - name: fabric_subscriber_id
          in: path
          required: true
          schema:
            type: string
      responses:
        '200':
          description: The request has succeeded.
          content:
            application/json:
              schema:
                type: object
      tags:
        - Subscribers
    patch:
      operationId: SubscriberSipEndpoint_update
      summary: Update Subscriber SIP Endpoint
      description: Updates a Subscriber Sip Endpoint by ID
      parameters:
        - name: id
          in: path
          required: true
          schema:
            type: string
        - name: fabric_subscriber_id
          in: path
          required: true
          schema:
            type: string
      responses:
        '200':
          description: The request has succeeded.
          content:
            application/json:
              schema:
                type: object
      tags:
        - Subscribers
      requestBody:
        required: true
        content:
          application/json:
            schema:
              type: object
  /resources/subscribers/{id}:
    get:
      operationId: Subscribers_get
      summary: Get Subscriber
      parameters:
        - name: id
          in: path
          required: true
          schema:
            type: string
      responses:
        '200':
          description: The request has succeeded.
          content:
            application/json:
              schema:
                type: object
      tags:
        - Subscribers
    put:
      operationId: Subscribers_update
      summary: Update Subscriber
      parameters:
        - name: id
          in: path
          required: true
          schema:
            type: string
      responses:
        '200':
          description: The request has succeeded.
          content:
            application/json:
              schema:
                type: object
      tags:
        - Subscribers
      requestBody:
        required: true
        content:
          application/json:
            schema:
              type: object
    delete:
      operationId: Subscribers_delete
      summary: Delete Subscriber
      parameters:
        - name: id
          in: path
          required: true
          schema:
            type: string
      responses:
        '204':
          description: 'There is no content to send for this request, but the headers may be useful. '
      tags:
        - Subscribers

Without any intervention outside of TypeSpec, is there a way to force the generation in a way where it will respect the ordering? Otherwise it will look a bit unorganized in a swagger viewer/ when we generate our Docusaurus docs.

In my actual setup, the sip_endpoint endpoint is being imported from another file, like so:

// Import necessary modules or types
import "@typespec/http";
import "./models/core.tsp";
import "./subscriber-sip-endpoint";
import "./models/requests.tsp";
import "./models/responses.tsp";
import "./models/errors.tsp";

using TypeSpec.Http;
using Types.StatusCodes;

// Define the API path for subscribers
@route("/resources/subscribers")
namespace FabricAPI.Subscribers {
    @tag("Subscribers")
    @friendlyName("Subscribers")
    interface Subscribers {
        @summary("List Subscribers")
        list(): Subscriber[];

        @summary("Create Subscriber")
        @post
        create(@body body: SubscriberRequest): 
        { @statusCode statusCode: 201; @body subscriber: SubscriberResponse; } |
        StatusCode401 |
        StatusCode404 |
        SubscriberCreateStatusCode422;

        @summary("Get Subscriber")
        get(...SubscriberPathID): 
        { @statusCode statusCode: 200; @body body: SubscriberResponse; } |
        StatusCode401 |
        StatusCode404;

        @summary("Update Subscriber")
        @put
        update(...SubscriberPathID, ...SubscriberRequest): 
        { @statusCode statusCode: 200; @body body: SubscriberResponse; } |
        StatusCode401 |
        StatusCode404 |
        SubscriberUpdateStatusCode422;

        @summary("Delete Subscriber")
        @delete
        delete(...SubscriberPathID): 
        { @statusCode statusCode: 204; } |
        StatusCode401 |
        StatusCode404;
    }
}