[RLC] Hybrid codegen#2338
Conversation
qiaozha
left a comment
qiaozha
left a comment
There was a problem hiding this comment.
left some small and probably naive comments :)
| "apiRefLink": "https://docs.microsoft.com/javascript/api/@msinternal/openai?view=azure-node-preview" | ||
| } | ||
| }, | ||
| "tshy": { |
There was a problem hiding this comment.
Is there a reason why we're not doing browser builds as part of RLC generation?
There was a problem hiding this comment.
I think it's because RLC types is meaningless as they are just generated for better user experience ?
| "apiRefLink": "https://docs.microsoft.com/javascript/api/@msinternal/openai?view=azure-node-preview" | ||
| } | ||
| }, | ||
| "tshy": { |
There was a problem hiding this comment.
I think it's because RLC types is meaningless as they are just generated for better user experience ?
joheredi
force-pushed
the
hybrid-codegen
branch
from
c3dc479 to
844fb1d
Compare
|
|
||
| if (model.options?.moduleKind === "cjs") { | ||
| mainEntryPointFilePath = `./types${ | ||
| generateTest || isModularLibrary ? "/src" : "" |
There was a problem hiding this comment.
we don't need to consider the generateSample here?
| model.options || {}; | ||
| const project = new Project(); | ||
|
|
||
| let mainEntryPointFilePath = "./dist/esm/index.d.ts"; |
There was a problem hiding this comment.
I am trying to understand if it's esm, we don't really need to compile the samples and tests? so does the cjs compile result? I mean in 'dist/commonjs' folder
qiaozha
left a comment
qiaozha
left a comment
There was a problem hiding this comment.
LGTM, just some minor comments
| "apiRefLink": "https://docs.microsoft.com/javascript/api/@msinternal/ai-anomaly-detector?view=azure-node-preview" | ||
| } | ||
| "main": "./dist/commonjs/index.js", | ||
| "types": "./dist/commonjs/index.d.ts" |
There was a problem hiding this comment.
Does that mean we will build types in both cjs and esm? Both of them are the extract same definitions?
| }, | ||
| "import": { | ||
| "types": "./dist/esm/index.d.ts", | ||
| "default": "./dist/esm/index.js" |
There was a problem hiding this comment.
Could you help me understand the dist structure here? How do we organize sample and test build codes? Will it be like:
dist/
├─ esm/
│ ├─ test/
│ ├─ samples-dev/
│ ├─ src?/
│ ├─ index.d.ts/ (whoes index file? src/sample/test?)
│ ├─ index.js/
.....
| "./src/**/*.ts", | ||
| "./src/**/*.mts", | ||
| "./src/**/*.cts", | ||
| "test/**/*.ts" |
There was a problem hiding this comment.
the test folder may not be always there? e.g if customers disable the test gen or in non-branded we disable test gen by default?
| "include": ${ | ||
| options.isAzureSdkForJs | ||
| ? `["dist-test/browser/**/*.spec.js"]` | ||
| : `["test/**/*.spec.ts"]` |
There was a problem hiding this comment.
i may not get the point that we need to distugsh with isAzureSdkForJs option with diff path?
| beforeEach(async function (this: Context) { | ||
| recorder = await createRecorder(this); | ||
| beforeEach(async function () { | ||
| // recorder = await createRecorder(this); |
There was a problem hiding this comment.
Does that mean the recorder is not working yet? if yes can we release this change?
| flavor | ||
| } = getAutorestOptions(); | ||
| const options: RLCOptions = {}; | ||
| const options: RLCOptions = { moduleKind: "cjs" }; |
There was a problem hiding this comment.
I'd like to clarify some details, there are two main changes
- changed to esm
- upgrade our build/test dependencies and steps
Are the two changes coupled with each other? Will the HLC need to adopt this? I mean if HLC won't adopt, can old code run correctly in SDK repo?
| }, | ||
| "react-native": { | ||
| "types": "./dist/react-native/index.d.ts", | ||
| "default": "./dist/react-native/index.js" |
There was a problem hiding this comment.
interesting, should the cjs code be the same as browser one after building?
another detail to confirm is that the replacement logic will be still working, right?
4 participants
Scoped to TypeSpec generation. Autorest generation should remain the same