The Storage SDK has been migrated to depend on the latest JavaScript core (v2) packages two years ago. We had to add a compatibility layer in order to avoid breaking changes in Storage public API surface. However, it adds additional maintenance cost, and Storage SDK remains an outlier because its API surface isn't consistent with the majority of our SDK packages. There are also patterns in the old autorest/swagger-based generator that we don't want carry forward to typespec-based generator. We are hoping to remove the compat layer and standardize Storage SDK packages so that their API surface is more aligned.
This document lists notable compatibility breaks if we remove the compat layer from, for example, @azure/storage-blob.
The option type passed to Client constructors will be different. Today customer can pass a StoragePipelineOptions option bag to a client constructor. After the changes they will pass a StorageClientOptions instead. The different options are:
audienceopti