feat: emit warp config instead of tshy for Azure monorepo packages#3802
feat: emit warp config instead of tshy for Azure monorepo packages#3802
Conversation
Replace tshy build configuration with warp for packages generated with azureSdkForJs=true. This generates a warp.config.yml file and resolved dist-level exports in package.json instead of inline tshy config. Changes: - Add buildWarpConfig.ts to generate warp.config.yml with targets for workerd, browser, react-native, esm, and commonjs - Update packageCommon.ts to emit warp entrypoints (main, module, types, browser, react-native) and resolved exports for monorepo packages - Remove tshy from monorepo devDependencies - Update buildPackageFile.ts to handle warp exports in update path - Wire up warp config builder in typespec-ts emitter - Update unit tests for new warp behavior Non-monorepo (standalone/flavorless) packages continue to use tshy. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
deyaaeldeen
requested review from
JialinHuang803,
MaryGao,
joheredi and
qiaozha
as code owners
The PR's change to skip tshy devDependency for azureSdkForJs packages (using warp instead) wasn't reflected in the 5 committed autorest test package.json files that default azureSdkForJs to true. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
…ibility Generated test packages have "type": "module" in their package.json, which triggers Node.js ESM loader when ts-node/register (v8) is used. The old ts-node/register only hooks into CJS require(), not the ESM loader, causing 'Unknown file extension .ts' errors. Replace ts-node with tsx for: - mocha --require hooks in integration/rlc/version-tolerance tests - standalone script execution (test commands, smoke test, copyFiles) Keep ts-node for unit tests since they don't import from ESM packages. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
MaryGao
left a comment
MaryGao
left a comment
There was a problem hiding this comment.
I wonder if we have any dependency for SDK change and codegen change?
@kazrael2119 Could you double comfirm the removal should be safe if we guareent the SDK pr merge first?
|
@deyaaeldeen do we need to adjust the SDK repo's status with package.json file first? |
|
@deyaaeldeen I've opened a new pull request, #3806, to work on those changes. Once the pull request is ready, I'll request review from you. |
* Initial plan * fix: don't overwrite existing warp.config.yml files Co-authored-by: deyaaeldeen <6074665+deyaaeldeen@users.noreply.github.com> --------- Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com> Co-authored-by: deyaaeldeen <6074665+deyaaeldeen@users.noreply.github.com>
No, warp is already in the repo and is preferred over tshy by dev-tool. First wave of migration is being done in Azure/azure-sdk-for-js#37372. |
|
Hi @deyaaeldeen my steps: do I miss some steps? |
|
@kazrael2119 Thanks for catching this issue. I pulled out the fix from Azure/azure-sdk-for-js#37372 in Azure/azure-sdk-for-js#37430. Could you try with that branch and let me know if there are any other issues? |
it passed with Azure/azure-sdk-for-js#37430 |
As the title says. Code gen is also generating warp configs: Azure/autorest.typescript#3802 Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Replace tshy build configuration with warp for packages generated with azureSdkForJs=true. This generates a warp.config.yml file and resolved dist-level exports in package.json instead of inline tshy config.
Changes:
Non-monorepo (standalone/flavorless) packages continue to use tshy.