Move to modern `@azure/*` packages with functional-style exports

[bwateratmsft]

🤖

Summary

Move the @azure/* dependencies to their most modern versions, which expose a functional-style (modular, tree-shakeable) API surface that bundles at a small fraction of the current size.

Motivation

Investigation into the 2.4.0 code-loading regression found that the Azure SDK packages dominate the lazily-loaded portion of the bundle. From a reachability analysis of the esbuild metafile (unminified byte counts, current main):

Package	Bytes in bundle
@azure/storage-blob	0.81 MB
@azure/arm-storage	0.54 MB
@azure/arm-containerregistry	0.37 MB
@azure/arm-resources	0.34 MB
@azure/arm-resources-profile-2020-09-01-hybrid	0.31 MB
@azure/arm-authorization	0.26 MB
@azure/storage-common	0.21 MB
@azure/arm-storage-profile-2020-09-01-hybrid	0.19 MB
others (arm-msi, arm-authorization-profile-*, core-*, …)	~0.6 MB

That is roughly 3.5 MB of the 4.73 MB that is reachable only via await import(). These are already lazily loaded via src/utils/lazyPackages.ts, so they are not on the activation critical path today — but they are the single largest contributor to overall bundle size, and they materially constrain any bundling strategy we choose.

The older client-class-based SDKs are effectively untreeshakeable: the generated clients pull in the full operation surface plus the @azure/core-* stack regardless of how few operations we actually call. The modern functional/modular exports are designed to be tree-shaken, so we would ship only the operations we use.

Current versions are also well behind:

• @azure/arm-containerregistry: ^10.1.0 (latest 12.0.0)
• @azure/storage-blob: ^12.14.0 (latest 12.33.0)

Expected benefits

• Substantially smaller VSIX and smaller on-disk footprint.
• Less code to read/parse whenever registry or blob functionality is first used.
• Meaningfully more headroom for whichever bundling approach we adopt (see below) — in particular it shrinks the duplicated @azure/core-* mass that any code-splitting scheme has to account for.
• Picks up several major versions of upstream fixes and security updates.

Scope

• @azure/arm-containerregistry — used via getArmContainerRegistry() in lazyPackages.ts; consumers include AzureRegistryDataProvider and related registry code.
• @azure/storage-blob — used via getStorageBlob().
• @microsoft/vscode-azext-azureutils transitively pulls @azure/arm-resources, arm-storage, arm-authorization, arm-msi and the *-profile-2020-09-01-hybrid variants. Reducing those likely requires a coordinated change in microsoft/vscode-azuretools rather than here.

Migrating to the functional API is a breaking-shape change at each call site (client classes → standalone operation functions), so this should be done deliberately with registry and blob-upload paths manually exercised.

Related

Part of the broader activation-performance work tracked from the 2.4.0 code-loading regression. Two adjacent items surfaced by the same investigation:

• The extension entry bundle grew from 1.84 MB (webpack, 2.3.0) to 2.85 MB (esbuild, 2.4.0+) because esbuild has no code splitting in CJS output, so lazily-imported code is inlined into the entry file instead of being emitted as separate on-demand chunks. This is the direct cause of the regression and is being addressed separately.
• @microsoft/vscode-azext-utils's parseError eagerly pulls in html-to-text (~0.25 MB, ~13% of the eager set). Worth a separate upstream issue against vscode-azuretools.

[bwateratmsft]

This may require comparable updates upstream in the azutils package.