search

Azure / autorest.typescript

Extension for AutoRest (https://github.com/Azure/autorest) that generates TypeScript code. The transpiled javascript code is isomorphic. It can be run in browser and in node.js environment.
MIT License
178 stars 75 forks source link

can't set expected client name for readme.md if set @@clientName in client.tsp #2698

Open kazrael2119 opened 3 months ago

kazrael2119 commented 3 months ago

https://github.com/Azure/autorest.typescript/pull/2697/files#diff-f204b0d6971e33587c7caa3083ebbd3d65060ab2bc38a140336a94b519c3c4e3R7 set client name in client.tsp but this client name doesn't work in readme.md https://github.com/Azure/autorest.typescript/pull/2697/files#diff-9c8451c7dabaf8ee5e1ccc587fdae3ee0d7df8bb7a49efdfe9d59aa42abc2ee4R31

qiaozha commented 3 months ago

In this issue, the client name we used in readme.md should come from Modular layer, however what we are using is the RLC client name. The root cause is currently we put the package.json readme.md generation into the rlc-common library, and we are leveraging the RLCModel to get all the information we need. See details from here

we could have three options to resolve this.

Option 1: we add the modularClientName in RLCModel and set this value in buildCodeModel emitClients

Pros:

  1. the implementation cost is not high.

Cons:

  1. we will probably need more information from modular model in the future. for example, generate some samples in the readme. it's not easy to extend this change to other scenarios.
  2. in multi client scenario, we have multiple modular clients, but we should still generate one readme.md file. we need more information and design about how the readme file should be look like.

Option 2: it doesn't really quite make sense to put the Modular metadata generation into rlc-common library. we could split the modular metadata generation out from rlc-common, and we could try to pass modular model to buildMetadata.

Pros:

  1. Our code will be more clearer.

Cons:

  1. we already have three different scenarios for metadata generation, Azure monorepo, azure standalone package, flavorless scenario, and each of them has to consider esm and commonjs config. it will probably duplicate a lot of effort if we split the modular metadata generation from rlc-common.

Option 3: we could change the Modular model interface to link it with RLC model. and try to pass modular model to createMetadata.

Pros:

  1. it might be a little more easy to extend for other scenarios.

Cons:

  1. Since we are trying to get rid of Modular code model to use SdkPackage completely, not sure if we still want to add modular and rlc model mapping. and we will probably add new more technical debt to the SdkPackage adoption.

Personally, I prefer option 3, because

  1. Since we will not adopt to tcgc for RLC, the RLC model will not be changing much even if we adopt tcgc for Modular layer maybe we could have a ModularCodeModel to extends from the SdkPackage, or have a wrapper to include SdkPackage type & RLC model reference, the new techinical debt might not be a concern?