Migrate cadl-ranch test to main typespec repo

timotheeguerin commented 3 months ago

As part of having the client emitters as well as trying to reuse the specs for service emitters it would be good to have cadl-ranch be directly into typespec

Currently there is a few packages in cadl-ranch:

cadl-ranch: Runtime
cadl-ranch-expect: Typespec library adding the custom decorators
cadl-ranch-api: TS Api to implement the mock api
cadl-ranch-dashboard: Website code
cadl-ranch-specs: The actual specs

I think we need could move and rename the following:

cadl-ranch: Runtime
cadl-ranch-expect: Typespec library adding the custom decorators
cadl-ranch-api: TS Api to implement the mock api

Then we can migrate the specs expect the azure ones.

The dashboard can remain there for now as it is specific to azure but that will be something that would be very nice to integrate as well

Things to figure out:

We need to be able to load multiple scenario set(Split between standard and azure specs)
New name?

Category	Runtime	TSP lib(decorators)	Mock api helpers	Test specs
Old Name	`@azure-tools/cadl-ranch`	`@azure-tools/cadl-ranch-expect`	`@azure-tools/cadl-ranch-api`	`@azure-tools/cadl-ranch-specs`
--------	-----------------------------	--------------------------------	-----------------------------	-------------------------------
Option 1	`@typespec/scenario-director`	`@typespec/scenario-lib`	`@typespec/scenario-api`	`@typespec/http-scenarios`
Option 2	`@typespec/tsp-cupboard`	`@typespec/tsp-cupboard-lib`	`@typespec/tsp-cupboard-api`	`@typespec/http-tsp-cupboard`
Option 3	`@typespec/tsp-recipes`	`@typespec/tsp-ingredients`	`@typespec/tsp-recipes-api`	`@typespec/http-recipes`
Option 4	`@typespec/spec-core`	`@typespec/spec`	`@typespec/spec` (we could reuse the same lib)	`@typespec/rest-spec`

Other alternatives:

cabinet instead of cupboard for option 2

Steps

- [x] Migrate the runtime + supporting packages(Keep specs there)
- [x] Design the service validation
- [x] Migrate specs from cadl-ranch-specs to the new raw typespec package
- [x] Backport the new definition api to cadl-ranch
- [x] Double check this is not breaking any emitter and fix
- [x] Migrate azure specs to typespec-azure
- [x] Remove need to have handler in 90% of case
- [x] ---- Rollout ----
- [ ] Work with getting a server test e2e working js/csharp
- [ ] Stubbing the cadl-ranch package for the typespec ones
- [x] Add support for loading multiple scenario set(pure typespec + azure for example)
- [ ] Work with emitters to make sure they call the new `tsp-spector` instead of `cadl-ranch`

markcowl commented 3 months ago

est: 8

timotheeguerin commented 3 months ago

Example what it could look like

function createModelMockApis(route: string, value: any[]): MockApiGetPut {
  const url = `/type/array/${route}`;
  return {
    get: {
      url,
      method: "get",
      request: {},
      repsonse: {
        status: 200,
        body: json(value),
      },
    },
    put: {
      url,
      method: "put",
      request: {
        body: json(value),
      },
      response: {
        status: 204,
      },
    },
  };
}

const Int32ValueMock = createModelMockApis("int32", [1, 2]);
Scenarios.Type_Array_Int32Value_get = passOnSuccess(Int32ValueMock.get);
Scenarios.Type_Array_Int32Value_put = passOnSuccess(Int32ValueMock.put);

Client testing flow

# Start mock server http://localhost:3000
tsp-spec server start ./node_modules/@typespec/rest-spec 

npm run client:test # Run all the emitted client tests - not our problem of what this do

tsp-spec server stop
# upload coverage

Server testing flow

npm run start:server:apis # Start the generated server - not our problem of what this do

# Run mock client tests
tsp-spec client run ./node_modules/@typespec/rest-spec

# upload coverage

Scenarios:

90:
- api.ts # 2 way format
10%: need both mockapi and mockclient
- mockapi.ts
- mockclient.ts

microsoft / typespec