Folder structure for services with multi sub services

[pshao25]

It's common for a service to have multiple sub services. Their spec structure is like

servicename:
  - Sub1.Management (TypeSpec)
  - Sub2.Management (TypeSpec)
  - resource-manager
  - - Sub1RP (swagger)
  - - Sub2RP (swagger)
  - - readme.md

In readme.md, it contains both Sub1RP (swagger) and Sub2RP (swagger).
In Sub1.Management is the TypeSpec for Sub1, while in Sub2.Management is the TypeSpec for Sub2.

This is an example:

Question: Where should we put the main.tsp?

Option 1: two main.tsps in both Sub1.Management and Sub2.Management
The problem is we have to generate 2 SDKs for Sub1.Management and Sub2.Management respectively. However, previously the readme.md contains two swaggers and we only have one SDK for this readme.md

Option 2: only one main.tsp importing specs from both Sub1.Management and Sub2.Management
The problem is only one swagger is generated, then we don't have Sub1RP and Sub2RP.

[qiaozha]

It's a general question for the conflict between typespec structure guideline https://github.com/Azure/azure-rest-api-specs/blob/main/documentation/typespec-structure-guidelines.md and swagger folder structure guideline https://github.com/Azure/azure-rest-api-specs/blob/main/documentation/directory-structure.md
In swagger, we are allowed to group a few sub services into the same package, but in TypeSpec, we can't because there's only one entry for tsp compile.

@josefree for awareness.

[markcowl]

This is by design, for two reasons:

• One of the major reasons for allowing this in swagger was to allow multiple api-versions of a service in a single SDK. This is no longer allowed, and will not be supported in TypeSpec
• Since TypeSpec is the source of truth, and a single, logiclal typespec spec can be split into multiple files or directories, there is no need for separate projects to separate concerns.

If there are any further questions or concerns, let's discuss