Enable verbatimModuleSyntax in azure-http-specs by timotheeguerin · Pull Request #5128 · Azure/typespec-azure

timotheeguerin · 2026-07-31T20:17:37Z

Type-only imports in typespec-azure are still emitted as runtime imports. That leaves dead runtime edges in the emitted JS, makes module side effects ambiguous, and blocks ever turning verbatimModuleSyntax on repo-wide — something core has already been rolling out package by package.

This enables the flag for azure-http-specs and rewrites the imports it flags:

-import { SdkContext } from "./interfaces.js";
+import type { SdkContext } from "./interfaces.js";

The rewrite was driven by the compiler rather than by regex: build the program with the flag on, collect the TS1484/TS1485/TS1205 diagnostics, and change exactly the specifiers TypeScript names — hoisting to import type when every specifier in a clause is type-only, otherwise adding an inline type modifier. tsc then reports zero new errors against a pre-change baseline, so no value binding was turned into a type-only one.

One of a series of PRs, one per package, so each diff stays reviewable. They are independent and can land in any order.

PR	Scope
#5127	`samples`, `typespec-python`, `benchmark`, `typespec-azure-playground-website`, `typespec-metadata`, `spector-runner`
#5128	`azure-http-specs`
#5129	`typespec-autorest`
#5130	`typespec-azure-core`
#5131	`typespec-azure-resource-manager`
#5132	`typespec-client-generator-core`
#5133	`typespec-go`
#5134	`typespec-ts`
#5135	`eng/` scripts

typespec-autorest-canonical, typespec-azure-portal-core and typespec-azure-rulesets already had the flag. typespec-java is deliberately left out: its src/ is copied in at build time from azure-sdk-for-java, so the flag would break its build until those sources are migrated upstream.

Once these land, a follow-up will hoist the flag into a repo-level tsconfig.base.json and drop the per-package copies, so new packages inherit it by default.

github-actions · 2026-07-31T20:21:05Z

All changed packages have been documented.

✅ @azure-tools/azure-http-specs

Show changes

`@azure-tools/azure-http-specs` - internal ✏️

Enable verbatimModuleSyntax and use import type for type-only imports. No runtime or public API changes.

pkg-pr-new · 2026-07-31T20:26:32Z

Open in StackBlitz

npm i https://pkg.pr.new/@azure-tools/azure-http-specs@5128

commit: 4bc478c

azure-sdk-automation · 2026-07-31T20:34:31Z

You can try these changes here

🛝 Playground	🌐 Website

…5132) Type-only imports in `typespec-azure` are still emitted as runtime imports. That leaves dead runtime edges in the emitted JS, makes module side effects ambiguous, and blocks ever turning `verbatimModuleSyntax` on repo-wide — something `core` has already been rolling out package by package. This enables the flag for **`typespec-client-generator-core`** and rewrites the imports it flags: ```diff -import { SdkContext } from "./interfaces.js"; +import type { SdkContext } from "./interfaces.js"; ``` The rewrite was driven by the compiler rather than by regex: build the program with the flag on, collect the TS1484/TS1485/TS1205 diagnostics, and change exactly the specifiers TypeScript names — hoisting to `import type` when every specifier in a clause is type-only, otherwise adding an inline `type` modifier. `tsc` then reports zero new errors against a pre-change baseline, so no value binding was turned into a type-only one. One of a series of PRs, one per package, so each diff stays reviewable. They are independent and can land in any order. | PR | Scope | | --- | --- | | Azure#5127 | `samples`, `typespec-python`, `benchmark`, `typespec-azure-playground-website`, `typespec-metadata`, `spector-runner` | | Azure#5128 | `azure-http-specs` | | Azure#5129 | `typespec-autorest` | | Azure#5130 | `typespec-azure-core` | | Azure#5131 | `typespec-azure-resource-manager` | | Azure#5132 | `typespec-client-generator-core` | | Azure#5133 | `typespec-go` | | Azure#5134 | `typespec-ts` | | Azure#5135 | `eng/` scripts | `typespec-autorest-canonical`, `typespec-azure-portal-core` and `typespec-azure-rulesets` already had the flag. `typespec-java` is deliberately left out: its `src/` is copied in at build time from `azure-sdk-for-java`, so the flag would break its build until those sources are migrated upstream. Once these land, a follow-up will hoist the flag into a repo-level `tsconfig.base.json` and drop the per-package copies, so new packages inherit it by default.

Type-only imports in `typespec-azure` are still emitted as runtime imports. That leaves dead runtime edges in the emitted JS, makes module side effects ambiguous, and blocks ever turning `verbatimModuleSyntax` on repo-wide — something `core` has already been rolling out package by package. This enables the flag for **the `eng/` scripts (`tsconfig.eng.json`)** and rewrites the imports it flags: ```diff -import { SdkContext } from "./interfaces.js"; +import type { SdkContext } from "./interfaces.js"; ``` The rewrite was driven by the compiler rather than by regex: build the program with the flag on, collect the TS1484/TS1485/TS1205 diagnostics, and change exactly the specifiers TypeScript names — hoisting to `import type` when every specifier in a clause is type-only, otherwise adding an inline `type` modifier. `tsc` then reports zero new errors against a pre-change baseline, so no value binding was turned into a type-only one. One of a series of PRs, one per package, so each diff stays reviewable. They are independent and can land in any order. | PR | Scope | | --- | --- | | Azure#5127 | `samples`, `typespec-python`, `benchmark`, `typespec-azure-playground-website`, `typespec-metadata`, `spector-runner` | | Azure#5128 | `azure-http-specs` | | Azure#5129 | `typespec-autorest` | | Azure#5130 | `typespec-azure-core` | | Azure#5131 | `typespec-azure-resource-manager` | | Azure#5132 | `typespec-client-generator-core` | | Azure#5133 | `typespec-go` | | Azure#5134 | `typespec-ts` | | Azure#5135 | `eng/` scripts | `typespec-autorest-canonical`, `typespec-azure-portal-core` and `typespec-azure-rulesets` already had the flag. `typespec-java` is deliberately left out: its `src/` is copied in at build time from `azure-sdk-for-java`, so the flag would break its build until those sources are migrated upstream. Once these land, a follow-up will hoist the flag into a repo-level `tsconfig.base.json` and drop the per-package copies, so new packages inherit it by default.

…#5131) Type-only imports in `typespec-azure` are still emitted as runtime imports. That leaves dead runtime edges in the emitted JS, makes module side effects ambiguous, and blocks ever turning `verbatimModuleSyntax` on repo-wide — something `core` has already been rolling out package by package. This enables the flag for **`typespec-azure-resource-manager`** and rewrites the imports it flags: ```diff -import { SdkContext } from "./interfaces.js"; +import type { SdkContext } from "./interfaces.js"; ``` The rewrite was driven by the compiler rather than by regex: build the program with the flag on, collect the TS1484/TS1485/TS1205 diagnostics, and change exactly the specifiers TypeScript names — hoisting to `import type` when every specifier in a clause is type-only, otherwise adding an inline `type` modifier. `tsc` then reports zero new errors against a pre-change baseline, so no value binding was turned into a type-only one. One of a series of PRs, one per package, so each diff stays reviewable. They are independent and can land in any order. | PR | Scope | | --- | --- | | Azure#5127 | `samples`, `typespec-python`, `benchmark`, `typespec-azure-playground-website`, `typespec-metadata`, `spector-runner` | | Azure#5128 | `azure-http-specs` | | Azure#5129 | `typespec-autorest` | | Azure#5130 | `typespec-azure-core` | | Azure#5131 | `typespec-azure-resource-manager` | | Azure#5132 | `typespec-client-generator-core` | | Azure#5133 | `typespec-go` | | Azure#5134 | `typespec-ts` | | Azure#5135 | `eng/` scripts | `typespec-autorest-canonical`, `typespec-azure-portal-core` and `typespec-azure-rulesets` already had the flag. `typespec-java` is deliberately left out: its `src/` is copied in at build time from `azure-sdk-for-java`, so the flag would break its build until those sources are migrated upstream. Once these land, a follow-up will hoist the flag into a repo-level `tsconfig.base.json` and drop the per-package copies, so new packages inherit it by default.

Type-only imports in `typespec-azure` are still emitted as runtime imports. That leaves dead runtime edges in the emitted JS, makes module side effects ambiguous, and blocks ever turning `verbatimModuleSyntax` on repo-wide — something `core` has already been rolling out package by package. This enables the flag for **`typespec-autorest`** and rewrites the imports it flags: ```diff -import { SdkContext } from "./interfaces.js"; +import type { SdkContext } from "./interfaces.js"; ``` The rewrite was driven by the compiler rather than by regex: build the program with the flag on, collect the TS1484/TS1485/TS1205 diagnostics, and change exactly the specifiers TypeScript names — hoisting to `import type` when every specifier in a clause is type-only, otherwise adding an inline `type` modifier. `tsc` then reports zero new errors against a pre-change baseline, so no value binding was turned into a type-only one. One of a series of PRs, one per package, so each diff stays reviewable. They are independent and can land in any order. | PR | Scope | | --- | --- | | Azure#5127 | `samples`, `typespec-python`, `benchmark`, `typespec-azure-playground-website`, `typespec-metadata`, `spector-runner` | | Azure#5128 | `azure-http-specs` | | Azure#5129 | `typespec-autorest` | | Azure#5130 | `typespec-azure-core` | | Azure#5131 | `typespec-azure-resource-manager` | | Azure#5132 | `typespec-client-generator-core` | | Azure#5133 | `typespec-go` | | Azure#5134 | `typespec-ts` | | Azure#5135 | `eng/` scripts | `typespec-autorest-canonical`, `typespec-azure-portal-core` and `typespec-azure-rulesets` already had the flag. `typespec-java` is deliberately left out: its `src/` is copied in at build time from `azure-sdk-for-java`, so the flag would break its build until those sources are migrated upstream. Once these land, a follow-up will hoist the flag into a repo-level `tsconfig.base.json` and drop the per-package copies, so new packages inherit it by default.

Type-only imports in `typespec-azure` are still emitted as runtime imports. That leaves dead runtime edges in the emitted JS, makes module side effects ambiguous, and blocks ever turning `verbatimModuleSyntax` on repo-wide — something `core` has already been rolling out package by package. This enables the flag for **`samples`, `typespec-python`, `benchmark`, `typespec-azure-playground-website`, `typespec-metadata` and `spector-runner`** and rewrites the imports it flags: ```diff -import { SdkContext } from "./interfaces.js"; +import type { SdkContext } from "./interfaces.js"; ``` The rewrite was driven by the compiler rather than by regex: build the program with the flag on, collect the TS1484/TS1485/TS1205 diagnostics, and change exactly the specifiers TypeScript names — hoisting to `import type` when every specifier in a clause is type-only, otherwise adding an inline `type` modifier. `tsc` then reports zero new errors against a pre-change baseline, so no value binding was turned into a type-only one. One of a series of PRs, one per package, so each diff stays reviewable. They are independent and can land in any order. | PR | Scope | | --- | --- | | Azure#5127 | `samples`, `typespec-python`, `benchmark`, `typespec-azure-playground-website`, `typespec-metadata`, `spector-runner` | | Azure#5128 | `azure-http-specs` | | Azure#5129 | `typespec-autorest` | | Azure#5130 | `typespec-azure-core` | | Azure#5131 | `typespec-azure-resource-manager` | | Azure#5132 | `typespec-client-generator-core` | | Azure#5133 | `typespec-go` | | Azure#5134 | `typespec-ts` | | Azure#5135 | `eng/` scripts | `typespec-autorest-canonical`, `typespec-azure-portal-core` and `typespec-azure-rulesets` already had the flag. `typespec-java` is deliberately left out: its `src/` is copied in at build time from `azure-sdk-for-java`, so the flag would break its build until those sources are migrated upstream. Once these land, a follow-up will hoist the flag into a repo-level `tsconfig.base.json` and drop the per-package copies, so new packages inherit it by default.

Type-only imports in `typespec-azure` are still emitted as runtime imports. That leaves dead runtime edges in the emitted JS, makes module side effects ambiguous, and blocks ever turning `verbatimModuleSyntax` on repo-wide — something `core` has already been rolling out package by package. This enables the flag for **`typespec-azure-core`** and rewrites the imports it flags: ```diff -import { SdkContext } from "./interfaces.js"; +import type { SdkContext } from "./interfaces.js"; ``` The rewrite was driven by the compiler rather than by regex: build the program with the flag on, collect the TS1484/TS1485/TS1205 diagnostics, and change exactly the specifiers TypeScript names — hoisting to `import type` when every specifier in a clause is type-only, otherwise adding an inline `type` modifier. `tsc` then reports zero new errors against a pre-change baseline, so no value binding was turned into a type-only one. One of a series of PRs, one per package, so each diff stays reviewable. They are independent and can land in any order. | PR | Scope | | --- | --- | | Azure#5127 | `samples`, `typespec-python`, `benchmark`, `typespec-azure-playground-website`, `typespec-metadata`, `spector-runner` | | Azure#5128 | `azure-http-specs` | | Azure#5129 | `typespec-autorest` | | Azure#5130 | `typespec-azure-core` | | Azure#5131 | `typespec-azure-resource-manager` | | Azure#5132 | `typespec-client-generator-core` | | Azure#5133 | `typespec-go` | | Azure#5134 | `typespec-ts` | | Azure#5135 | `eng/` scripts | `typespec-autorest-canonical`, `typespec-azure-portal-core` and `typespec-azure-rulesets` already had the flag. `typespec-java` is deliberately left out: its `src/` is copied in at build time from `azure-sdk-for-java`, so the flag would break its build until those sources are migrated upstream. Once these land, a follow-up will hoist the flag into a repo-level `tsconfig.base.json` and drop the per-package copies, so new packages inherit it by default.

Enable verbatimModuleSyntax in azure-http-specs

4bc478c

microsoft-github-policy-service Bot added the lib:azure-http-specs For issues/prs related to the @azure-tools/typespec-azure-http-specs package label Jul 31, 2026

timotheeguerin marked this pull request as ready for review July 31, 2026 21:45

timotheeguerin requested review from iscai-msft, jhendrixMSFT, lmazuel, m-nash, markcowl, tadelesh, weidongxu-microsoft and xirzec as code owners July 31, 2026 21:45

timotheeguerin enabled auto-merge July 31, 2026 21:56

xirzec approved these changes Jul 31, 2026

View reviewed changes

timotheeguerin added this pull request to the merge queue Jul 31, 2026

github-merge-queue Bot removed this pull request from the merge queue due to failed status checks Jul 31, 2026

timotheeguerin added this pull request to the merge queue Aug 1, 2026

Merged via the queue into Azure:main with commit aa0f16a Aug 1, 2026
44 checks passed

timotheeguerin deleted the vms/azure-http-specs branch August 1, 2026 00:35

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Enable verbatimModuleSyntax in azure-http-specs - #5128

Enable verbatimModuleSyntax in azure-http-specs#5128
timotheeguerin merged 1 commit into
Azure:mainfrom
timotheeguerin:vms/azure-http-specs

timotheeguerin commented Jul 31, 2026 •

edited

Loading

Uh oh!

github-actions Bot commented Jul 31, 2026

`@azure-tools/azure-http-specs` - internal ✏️

Uh oh!

pkg-pr-new Bot commented Jul 31, 2026

Uh oh!

azure-sdk-automation Bot commented Jul 31, 2026

Uh oh!

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

timotheeguerin commented Jul 31, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

github-actions Bot commented Jul 31, 2026

@azure-tools/azure-http-specs - internal ✏️

Uh oh!

pkg-pr-new Bot commented Jul 31, 2026

Uh oh!

azure-sdk-automation Bot commented Jul 31, 2026

Uh oh!

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

timotheeguerin commented Jul 31, 2026 •

edited

Loading

`@azure-tools/azure-http-specs` - internal ✏️