feat: add UseTypeSpecNext support for C# emitter pipeline#10370
Open
JoshLove-msft wants to merge 10 commits intomicrosoft:mainfrom
Open
feat: add UseTypeSpecNext support for C# emitter pipeline#10370JoshLove-msft wants to merge 10 commits intomicrosoft:mainfrom
JoshLove-msft wants to merge 10 commits intomicrosoft:mainfrom
Conversation
Add a common reusable script (eng/emitters/scripts/Update-TypeSpecNext.ps1) that uses @azure-tools/typespec-bump-deps to update TypeSpec dependencies to their @next versions. The script only mutates package manifests and can be adopted by any emitter. Implement the UseTypeSpecNext branch in the C# Initialize-Repository.ps1 and expose the flag as a pipeline parameter in the C# publish pipeline so operators can toggle it on manual runs. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
JoshLove-msft
requested review from
ShivangiReja,
christothes,
iscai-msft,
jorgerangel-msft,
joseharriaga,
jsquire,
m-nash,
srnagar and
timotheeguerin
as code owners
microsoft-github-policy-service
bot
added
emitter:client:csharp
Move the npx @azure-tools/typespec-bump-deps invocation from the PowerShell wrapper script into build-step.yml as a conditional pipeline step. This gives better visibility in the Azure DevOps UI, makes the step truly common across all emitters, and matches the Python approach. - Add conditional step in build-step.yml to run typespec-bump-deps - Remove eng/emitters/scripts/Update-TypeSpecNext.ps1 - Simplify C# Initialize-Repository.ps1 to only handle npm install Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
When typespec-bump-deps updates dependencies to @next versions, transitive peer dependency constraints may not yet be satisfied (e.g. azure-core@next still declares peerDep on compiler@^1.11.0 while compiler@1.12.0-dev is installed). Use --legacy-peer-deps to skip strict peer dep resolution, matching the behavior of pnpm --no-frozen-lockfile used by Python. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
With @next versions, transitive peer dependency mismatches are expected (e.g. azure-core@next may still declare peer on compiler@^1.11.0 while compiler@1.12.0-dev is installed). Use -IgnoreExitCode on npm ls to prevent the pipeline from failing on these expected warnings. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Invoke-LoggedCommand -IgnoreExitCode suppresses the error message but does not reset $LASTEXITCODE. PowerShell then exits with code 1, causing the ADO task to fail. Explicitly reset to 0 after the call. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
jorgerangel-msft
approved these changes
Apr 14, 2026
commit: |
Contributor
|
No changes needing a change description found. |
The tsp-client generate-config-files command runs npm install internally, which fails on peer dep conflicts with @next versions. Set npm config legacy-peer-deps=true before the CreateAzureSdkForNetPR stage when UseTypeSpecNext is enabled. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
The Submit-AzureSdkForNetPr.ps1 script sets NPM_CONFIG_USERCONFIG to a custom .npmrc for registry auth, which overrides the user-level .npmrc where 'npm config set' writes. Use the npm_config_legacy_peer_deps environment variable instead, which takes precedence over all .npmrc files and is inherited by child processes (tsp-client's internal npm install). Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
--legacy-peer-deps skips installing conflicting peer deps entirely, causing packages like @typespec/streams and @typespec/events to be missing at runtime. --force installs all packages including peer deps but ignores version conflicts. Also set TSPCLIENT_FORCE_INSTALL=true for tsp-client's internal npm install (tsp-client already supports this env var natively). Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
The test stage calls Initialize-Repository.ps1 with -BuildArtifactsPath which uses npm ci (strict peer dep enforcement). When UseTypeSpecNext is true, npm ci needs --force to handle peer dep conflicts in @next packages. Thread UseTypeSpecNext through emitter-stages.yml -> test-job.yml -> test-step.yml -> Initialize-Repository.ps1 so the test leg uses npm ci --force when needed. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Adds the ability to run the C# emitter pipeline against TypeSpec @next versions, enabling validation of upcoming TypeSpec changes before they are released.
Changes
Common pipeline template (�ng/emitters/pipelines/templates/steps/build-step.yml)
px @azure-tools/typespec-bump-deps@latest --use-peer-ranges package.json when UseTypeSpecNext is rue
C# publish pipeline (packages/http-client-csharp/eng/pipeline/publish.yml)
C# Initialize-Repository.ps1
pm install instead of
pm ci, since the lockfile will be stale after dependency bumping
How it works
pm install (instead of
pm ci) since the lockfile no longer matches the bumped package.json
Usage
In the Azure DevOps publish pipeline, toggle "Use TypeSpec Next" when manually queuing a build. The published emitter package will use TypeSpec @next dependencies and can be used to regenerate azure-sdk-for-net.
Other emitters (Java, Python) can adopt the same pattern by implementing the UseTypeSpecNext branch in their Initialize-Repository.ps1 scripts — the common pipeline step already handles the dep bumping.