Ashwin Mayya: JS SDK Validation check failing with package name mismatch
posted in Azure SDK / API Spec Review on Wednesday, July 23, 2025 3:29 PM
This is a user reported issue related to SDK Validation failures. The root cause has been identified as incorrect setting for ‘@azure-tools/typespec-ts/package-details’ in the ‘tspconfig.yaml’ file. The error surfaced in the JS automation doesn’t indicate the real issues or suggest actionable fixes. Although we already have the ‘SdkTspConfigValidation’ rule in the TSV Validation check, it is currently suppressed for this service.
Since SDK Validation checks are now required, and incorrect emitter options might fail these checks, which turns out blocking the PR merge. To reduce repeated support efforts for these types of configuration issues, I propose leveraging the TSV Validation check to surface these errors more transparently. This aligns with the original intent behind adding these rules.
I know last time Mike tried to scope suppressions to only apply in ‘checkAll’ scenario, but it was reverted due to broadly impact to service teams.
To move forward, I suggest dividing suppressions into two groups:
#1 suppressions on specific emitter options, we should make them invalid on service spec PR.
#2 suppressions on emitter itself, these can remain as some service teams may opt out of SDK generation.
@wanlwanl could you make the suppression changes?
//CC: @maririos @weshaggard @mikeharder
Ashwin Mayya: JS SDK Validation check failing with package name mismatch
posted in Azure SDK / API Spec Review on Wednesday, July 23, 2025 3:29 PM
This is a user reported issue related to SDK Validation failures. The root cause has been identified as incorrect setting for ‘@azure-tools/typespec-ts/package-details’ in the ‘tspconfig.yaml’ file. The error surfaced in the JS automation doesn’t indicate the real issues or suggest actionable fixes. Although we already have the ‘SdkTspConfigValidation’ rule in the TSV Validation check, it is currently suppressed for this service.
Since SDK Validation checks are now required, and incorrect emitter options might fail these checks, which turns out blocking the PR merge. To reduce repeated support efforts for these types of configuration issues, I propose leveraging the TSV Validation check to surface these errors more transparently. This aligns with the original intent behind adding these rules.
I know last time Mike tried to scope suppressions to only apply in ‘checkAll’ scenario, but it was reverted due to broadly impact to service teams.
To move forward, I suggest dividing suppressions into two groups:
#1 suppressions on specific emitter options, we should make them invalid on service spec PR.
#2 suppressions on emitter itself, these can remain as some service teams may opt out of SDK generation.
@wanlwanl could you make the suppression changes?
//CC: @maririos @weshaggard @mikeharder