### Packages impacted by this PR
@azure/core-client-rest
@azure/ts-http-runtime
### Issues associated with this PR
N/A - found in passing
### Describe the problem that is addressed by this PR
The existing regex for finding template values to replace assumes only
`\w` characters are allowed in the template, but
`-` should be valid for a template name
After moving to ESM/tshy, we no longer build tests/samples. This PR
enables running "typecheck" as an optional rush bulk command, and fixes
some of the errors found.
The known errors reported on files from vite/vitest/chai are ignored.
The update-snippets dev-tool command throws error of reading undefined
in some cases, adding a null check fixes it.
Snippets are updated as well after snippets.spec.ts files are fixed.
- apply lint:fix results
- revert fixes that are not related to consistent-type-imports and cases error
- regenerate .api.md files
- format
- update core-comparison diff
### Packages impacted by this PR
- `@azure-rest/core-client`
### Describe the problem that is addressed by this PR
Simplify `isCredential` helper used in getClient.ts. This change was
already made in the unbranded package but not in Azure core.
No change in the Unbranded diff report for this PR because I made the
change and updated the diff as part of #31487, just forgot to check in
this particular change. The unbranded diff check is currently reporting
a failure on main and this change should fix that.
### Packages impacted by this PR
- `@azure-rest/core-client`
### Issues associated with this PR
- Fix https://github.com/Azure/azure-sdk-for-js/issues/31349
### Describe the problem that is addressed by this PR
We generate RLCs that allow for path parameters to be `number`. The
change for `allowReserved` assumed that path parameters could only be
`string`, causing number parameters to not be serialized properly. This
PR fixes that assumption.
### What are the possible designs available to address the problem? If
there are more than one possible design, why was the one in this PR
chosen?
### Are there test cases added in this PR? _(If not, why?)_
Added a test to check for a number path parameter
### Provide a list of related PRs _(if any)_
- #31058
### Packages impacted by this PR
- `@azure-rest/core-client`
### Issues associated with this PR
- Fixes#30943
- Fixes#30944
### Describe the problem that is addressed by this PR
Adds support for passing in an object as a query or path parameter. At
present, this object allows for the user to specify a couple of
encoding-related options in addition to the value of the parameter:
- For path parameters: `allowReserved` can be set to true to indicate
that special characters appearing in the parameter should not be
URL-encoded. This allows for path parameters to contain characters like
`/`.
- For query parameters: `explode` can be set to true to change how
arrays are encoded. By default, array values are encoded as a single
query parameter, with each value separated by a comma (e.g. `foo=a,b,c`.
With `explode` set to true, each array value will be converted into a
single query parameter (e.g. `foo=a&foo=b&foo=c`).
### Packages impacted by this PR
- @azure/dev-tool
- @azure/abort-controller
- @azure/core-amqp
- @azure/core-auth
- @azure/core-client
- @azure-rest/core-client
- @azure/core-http-compat
- @azure/core-lro
- @azure/core-paging
- @azure/core-rest-pipeline
- @azure/core-tracing
- @azure/core-util
- @azure/core-xml
- @azure/logger
- @typespec/ts-http-runtime
### Issues associated with this PR
### Describe the problem that is addressed by this PR
Adds snippets extraction to core.
### What are the possible designs available to address the problem? If
there are more than one possible design, why was the one in this PR
chosen?
### Are there test cases added in this PR? _(If not, why?)_
### Provide a list of related PRs _(if any)_
### Command used to generate this PR:**_(Applicable only to SDK release
request PRs)_
### Checklists
- [ ] Added impacted package name to the issue description
- [ ] Does this PR needs any fixes in the SDK Generator?** _(If so,
create an Issue in the
[Autorest/typescript](https://github.com/Azure/autorest.typescript)
repository and link it here)_
- [ ] Added a changelog (if necessary)
- [eslint-plugin] github-source-headers rule should use "MIT License".
This change updates our linter rule and the whole repository to have consistent
license header.
***NO_CI***
- remove "All rights reserved." from header
- "MIT license" => "MIT License"
***NO_CI***
- bump typescript-eslint dependencies version to ~8.2.0
- [eslint-plugin] suppress new linting errors appearing with v8
- [eslint-plugin] react to removed typescript-eslint property
related PR https://github.com/typescript-eslint/typescript-eslint/pull/9025
- [eslint-plugin] turn off @typescript-eslint/no-unused-expressions
as no-unused-expressions is already reported by eslint
- [dev-tool] fix new linting errors
- Remove @typescript-eslint/ban-types that no longer exists
and replace with more specific rules wherever applicable.
- [cosmosdb] combine the test eslint config with the main one
- delete catch expression when caught error is not used
- fix or suppress linting errors in code files
### Packages impacted by this PR
@azure-rest/core-client
### Issues associated with this PR
### Describe the problem that is addressed by this PR
Fix typo in common.ts
There's some behavior change that adds parentheses for nullish coalescing in
ternary. So we will need to re-format our code base.
- remove prettier from packages that don't need them since we run the vendored
version via dev-tool
### Describe the problem that is addressed by this PR
Currently, all request body that has content types that start with
"application/json" will be serialized by the `getRequestBody` function.
This is an issue for Schema Registry because the request body has
already been serialized and the content type also starts with
"application/json". Reordering the serialization method to check for
`Uint8Array` before checking for "application/json" would eliminate this
problem.
### What are the possible designs available to address the problem? If
there are more than one possible design, why was the one in this PR
chosen?
- Add an option called `skipSerialization` in the internal options bag
for sending request. It'll affect the RLC experience and force the
customer to use this option to make a successful request
- Check for specific content types. It'll be limited in scope and affect
other services that also has a similar content type format
### Packages impacted by this PR
- `@azure-rest/core-client`
### Describe the problem that is addressed by this PR
Proposal to mitigate a couple of breaking changes between the old and
new `core-client` packages:
- `onResponse` is now called when an error is thrown while sending the
request. This was not being done by `core-client-rest` but [is being
done by `core-client`
](9f03724468/sdk/core/core-client/src/serviceClient.ts (L217-L229)).
- Updated the type of the `onResponse` callback to be more
backwards-compatible with the old Core. The old Core's callback had
three parameters (response, flatResponse, and error), but the new
package has only two (response and error). The `flatResponse` property
does not make sense in the new Core and we have decided not to support
this property. In order to enable this, we pass the error twice in the
new callback so that we can support passing the `error` through to both
the old and new variations of `onResponse`.
### Packages impacted by this PR
- `@azure/core-client-rest`
### Issues associated with this PR
- Resolves#28971
### Describe the problem that is addressed by this PR
- Major bump of `@azure-rest/core-client` to 2.0.0 due to introduced
behavioral breaking change.
- The expected body shape for `multipart/form-data` is now an array of
`PartDescriptor`, which has the following fields:
- `headers` and `body` representing the multipart request headers and
body
- Convenience fields for MIME header values:
- `contentType`, for the `Content-Type` MIME header
- `name`, `filename`, `dispositionType`, for constructing the
`Content-Disposition` MIME header
- These convenience values take precedence over any existing MIME
information (name and filename) present in the request body (i.e. the
`name` property on `File` and the `type` property on both `File` and
`Blob`)
- If the headers are set explicitly in the `headers` bag, the headers
bag value takes precedence above all.
- Implemented part serialization flowchart more or less as described in
the Loop, with a couple of notable differences (and other less notable
ones):
- `string` values are put directly on the wire regardless of content
type; this allows for customers to pass pre-serialized JSON to the
service
- If no content type is specified, and we cannot infer the content type,
we default to `application/json` (i.e. there is no situation where we
would throw a "cannot encode type" error)
- Added support for `FormData` objects. If a `FormData` object is
encountered, it is passed directly to `core-rest-pipeline` for it to
handle.
### Are there test cases added in this PR? _(If not, why?)_
Yes
### To do
- [ ] Port Core change to ts-http-runtime before merging
### Packages impacted by this PR
@azure-rest/core-client
### Issues associated with this PR
https://github.com/Azure/autorest.typescript/issues/2210
### Describe the problem that is addressed by this PR
we can't have a way to pass accept header to the core now. although we
can do that in RLC as it's defined in
93cbd84e4a/sdk/core/core-client-rest/src/common.ts (L34),
but in modular, the operation options is extended from
93cbd84e4a/sdk/core/core-client-rest/src/common.ts (L121)
we need to leverage the headers for accept for this to work in Modular.
### What are the possible designs available to address the problem? If
there are more than one possible design, why was the one in this PR
chosen?
### Are there test cases added in this PR? _(If not, why?)_
### Provide a list of related PRs _(if any)_
### Command used to generate this PR:**_(Applicable only to SDK release
request PRs)_
### Checklists
- [ ] Added impacted package name to the issue description
- [ ] Does this PR needs any fixes in the SDK Generator?** _(If so,
create an Issue in the
[Autorest/typescript](https://github.com/Azure/autorest.typescript)
repository and link it here)_
- [ ] Added a changelog (if necessary)
### Packages impacted by this PR
- @azure/abort-controller
- @azure/core-auth
- @azure/core-client
- @azure-rest/core-client
- @azure/core-http-compat
- @azure/core-lro
- @azure/core-paging
- @azure/core-rest-pipeline
- @azure/core-sse
- @azure/core-tracing
- @azure/core-util
- @azure/core-xml
- @azure/logger
- @typespec/ts-http-runtime
### Issues associated with this PR
### Describe the problem that is addressed by this PR
This migrates the core packages from a hybrid of CJS and ESM to an ESM
solution using [`tshy`](https://github.com/isaacs/tshy). The core is now
ESM, implemented as a module, and projects using `tshy` to CommonJS and
ESM.
The ESM build targets we will target include:
- ESM (Node)
- Browser
- React-Native
- Bun
- Deno
This will allow each system to pick up the correct output instead of
picking the browser bundle which has happened in the past. Currently,
our bun and deno support is strictly through npm compatibility and we
are not forking logic at this point for those runtimes.
In order to support ESM, `sinon` does not allow for ESM module mocking,
so we looked for an alterative in `vitest`. This PR also migrates all
core packages stated above from Mocha/Chai for Node and Mocha/Chai/Karma
for the browser to using `vitest` for all tests. Currently, the system
builds a test bundle which targets the correct files such as those
targeted for the browser, eg `log-browser.mts` becomes `log.js` in the
compiled output.
### What are the possible designs available to address the problem? If
there are more than one possible design, why was the one in this PR
chosen?
### Are there test cases added in this PR? _(If not, why?)_
### Provide a list of related PRs _(if any)_
### Command used to generate this PR:**_(Applicable only to SDK release
request PRs)_
### Checklists
- [ ] Added impacted package name to the issue description
- [ ] Does this PR needs any fixes in the SDK Generator?** _(If so,
create an Issue in the
[Autorest/typescript](https://github.com/Azure/autorest.typescript)
repository and link it here)_
- [ ] Added a changelog (if necessary)
---------
Co-authored-by: Deyaaeldeen Almahallawi <dealmaha@microsoft.com>
Co-authored-by: Maor Leger <maorleger@users.noreply.github.com>
Co-authored-by: Jeremy Meng <jeremy.ymeng@gmail.com>
fix
https://github.com/Azure/autorest.typescript/pull/2032#discussion_r1349470618
fix https://github.com/Azure/autorest.typescript/issues/2207
In this PR,
1. we allow customer to set their customized content type via
options.contentType or content-type header. where options.contentType
has higher priority than content-type header.
2. we set the default content-type to text/plain if it's non-json string
in the body, but remain to be application/json if it's json string.
---------
Co-authored-by: Deyaaeldeen Almahallawi <dealmaha@microsoft.com>
### Packages impacted by this PR
- `@azure/core-rest-pipeline`
### Issues associated with this PR
- #28102
- Fixes https://github.com/Azure/autorest.typescript/issues/2177
### Describe the problem that is addressed by this PR
- Added private "raw content" property to `createFile`-created `File`s
to work around a couple of Node bugs (one where `Blob#stream` doesn't
work in certain versions of Node 20, and another where
`Readable.fromWeb` doesn't work in certain versions of Node 18). The
"raw" property is used to get the original stream instead of the
`stream` method. This property is used when accessing the stream so we
don't have to convert to/from web streams, cirvumventing the two issues.
- In browser, multipartPolicy now concatenates `Blob` objects using the
`Blob` constructor instead of concatenating `ReadableStream`s. This
works around the fact that `ReadableStream` is not a supported request
body type when using HTTP/1.1 in the browser (see #28102).
- We are still using the browser-mapped formDataPolicy for now, but this
should unblock us returning to the isomorphic multipartPolicy-based
formDataPolicy if it provides a benefit in future.
- See this doc for some interesting reading on the design of the `Blob`
API as it is implemented by Chromium:
https://chromium.googlesource.com/chromium/src/+/HEAD/storage/browser/blob/README.md.
Notably, large `Blob`s may be put on disk when created, and creating a
new `Blob` by concatenating other `Blob`s does not involve an expensive
copy.
### Packages impacted by this PR
- `@azure-rest/core-client`
### Issues associated with this PR
- https://github.com/Azure/autorest.typescript/issues/2197
### Describe the problem that is addressed by this PR
We have upcoming RLCs requiring uploading multiple files in the same
parameter. This is supported by core-rest-pipeline already but we don't
currently convert `Uint8Array` to `Blob` in core-client-rest as is
required by the form data policy.
### Are there test cases added in this PR? _(If not, why?)_
Yes!
---------
Co-authored-by: Jeff Fisher <xirzec@xirzec.com>
### Packages impacted by this PR
@azure-rest/core-client and @azure/openai
### Issues associated with this PR
https://github.com/Azure/azure-sdk-for-js/issues/28093
### Describe the problem that is addressed by this PR
The `onResponse` callback option is not called in `streamCompletions`
and `streamChatCompletions`. This is because the `asNodeStream` and
`asBrowserStream` methods in the internal client don't call them.
### What are the possible designs available to address the problem? If
there are more than one possible design, why was the one in this PR
chosen?
This PR addresses the issue by simply calling the onResponse call back
in the `asNodeStream` and `asBrowserStream` methods. I don't think we
want to _not_ call onResponse there.
### Are there test cases added in this PR? _(If not, why?)_
Yes
### Provide a list of related PRs _(if any)_
N/A
### Command used to generate this PR:**_(Applicable only to SDK release
request PRs)_
### Checklists
- [x] Added impacted package name to the issue description
- [ ] Does this PR needs any fixes in the SDK Generator?** _(If so,
create an Issue in the
[Autorest/typescript](https://github.com/Azure/autorest.typescript)
repository and link it here)_
- [x] Added a changelog (if necessary)
using `dev-tool run vendored` command. This allows us to remove
dependency on
`prettier` from the packages' dependency list which helps maintenance.
### Issues associated with this PR
#27909
### Packages impacted by this PR
- `@azure-rest/core-client`
### Describe the problem that is addressed by this PR
- Remove conversion of Uint8Array to binary string with
`application/octet-stream` content type
- `core-rest-pipeline` handles Uint8Array as a request body type so this
conversion should not be necessary
- Remove conversion of Uint8Array to binary string in
`multipart/form-data` requests and convert to `Blob` instead
- With the new multipart work, support for `Blob` is much improved and
this workaround should no longer be required.
### Packages impacted by this PR
@azure-rest/core-client
### Issues associated with this PR
https://github.com/Azure/autorest.typescript/pull/1997#discussion_r1401339120
### Describe the problem that is addressed by this PR
### What are the possible designs available to address the problem? If
there are more than one possible design, why was the one in this PR
chosen?
### Are there test cases added in this PR? _(If not, why?)_
### Provide a list of related PRs _(if any)_
### Command used to generate this PR:**_(Applicable only to SDK release
request PRs)_
### Checklists
- [ ] Added impacted package name to the issue description
- [ ] Does this PR needs any fixes in the SDK Generator?** _(If so,
create an Issue in the
[Autorest/typescript](https://github.com/Azure/autorest.typescript)
repository and link it here)_
- [ ] Added a changelog (if necessary)
Currently we convert request body to string by default. This isn't
always desirable and could be problematic. It breaks Image Analysis
scenario where request body needs to be raw bytes.
This PR keeps the raw bytes as the request body when the content type is
`applicatoni/octect-stream`. This is a short-term fix to unblock Image
Analysis SDK while we investigate for better and long term solutions.
### Packages impacted by this PR
`@azure-rest/core-client`
### Issues associated with this PR
#27748
### Packages impacted by this PR
`@azure-rest/core-client`
### Issues associated with this PR
https://github.com/Azure/autorest.typescript/issues/1916
### Describe the problem that is addressed by this PR
Since we were using spread syntax on `RequestParameters` if an
`undefined` value was passed this would take precedence over the client
option, which was not expected.
This PR switches the order of when the spread happens while still
pulling the value from `RequestParameters` when present.
### Are there test cases added in this PR? _(If not, why?)_
Yes!
fixes https://github.com/Azure/autorest.typescript/issues/1902
This PR is trying to map the
[OperationOptions](https://github.com/Azure/azure-sdk-for-js/blob/main/sdk/core/core-client/src/interfaces.ts#L98-L122)
from @azure/core-client to
[RequestParameters](https://github.com/Azure/azure-sdk-for-js/blob/main/sdk/core/core-client-rest/src/common.ts#L19-L51)
in @azure-rest/core-client.
As the API layer internally call rest layer, we should provide every
functionality that the high level core-client @azure-rest/core-client
has and map them to the rest level core-client @azure-rest/core-client.
right now I have added `abortSignal`, `tracingOptions`, `onResponse`
into the RequestParameters.
```typescript
/**
* The signal which can be used to abort requests.
*/
abortSignal?: AbortSignalLike;
/**
* Options used when tracing is enabled.
*/
tracingOptions?: OperationTracingOptions;
/**
* A function to be called each time a response is received from the server
* while performing the requested operation.
* May be called multiple times.
*/
onResponse?: RawResponseCallback;
```
And inside the `requestOptions`, I have added `timeout`,
`onUploadProgress`, `onDownloadProgress` and flattened it in the top
level of `RequestParameters`
```typescript
/**
* The number of milliseconds a request can take before automatically being terminated.
*/
timeout?: number;
/**
* Callback which fires upon upload progress.
*/
onUploadProgress?: (progress: TransferProgressEvent) => void;
/**
* Callback which fires upon download progress.
*/
onDownloadProgress?: (progress: TransferProgressEvent) => void;
```
Also, add an interface OperationOptions in @azure-rest/core-client, for
modular usage in specify these options.
```typescript
export interface OperationOptions {
/**
* The signal which can be used to abort requests.
*/
abortSignal?: AbortSignalLike;
/**
* Options used when creating and sending HTTP requests for this operation.
*/
requestOptions?: OperationRequestOptions;
/**
* Options used when tracing is enabled.
*/
tracingOptions?: OperationTracingOptions;
/**
* A function to be called each time a response is received from the server
* while performing the requested operation.
* May be called multiple times.
*/
onResponse?: RawResponseCallback;
}
```
### Packages impacted by this PR
@azure-rest/core-client
### Issues associated with this PR
### Describe the problem that is addressed by this PR
### What are the possible designs available to address the problem? If
there are more than one possible design, why was the one in this PR
chosen?
### Are there test cases added in this PR? _(If not, why?)_
### Provide a list of related PRs _(if any)_
### Command used to generate this PR:**_(Applicable only to SDK release
request PRs)_
### Checklists
- [ ] Added impacted package name to the issue description
- [ ] Does this PR needs any fixes in the SDK Generator?** _(If so,
create an Issue in the
[Autorest/typescript](https://github.com/Azure/autorest.typescript)
repository and link it here)_
- [ ] Added a changelog (if necessary)
### Packages impacted by this PR
@azure-rest/core-client
### Issues associated with this PR
### Describe the problem that is addressed by this PR
In the apiVersionPolicy, we use url.toString() to get the final url,
which will encode everything and ruin our effort in buildRequestUrl even
if we have passed skipUrlEncoding.
### What are the possible designs available to address the problem? If
there are more than one possible design, why was the one in this PR
chosen?
### Are there test cases added in this PR? _(If not, why?)_
### Provide a list of related PRs _(if any)_
### Command used to generate this PR:**_(Applicable only to SDK release
request PRs)_
### Checklists
- [x] Added impacted package name to the issue description
- [ ] Does this PR needs any fixes in the SDK Generator?** _(If so,
create an Issue in the
[Autorest/typescript](https://github.com/Azure/autorest.typescript)
repository and link it here)_
- [x] Added a changelog (if necessary)
### Packages impacted by this PR
@azure-rest/core-client
### Issues associated with this PR
https://github.com/Azure/azure-sdk-for-js/issues/24982
### Describe the problem that is addressed by this PR
Currently core-client-rest fills in parameterized paths assuming that
there will be only one parametrized element in a given path part. As
surfaced in the linked issue, there are scenarios where a single path
part can have more than one parameter.
### What are the possible designs available to address the problem? If
there are more than one possible design, why was the one in this PR
chosen?
Currently we only consider `/` as a delimiter to look for the next path
parameter. Adding `,` as a delimiter addresses this issue.
### Are there test cases added in this PR? _(If not, why?)_
Yes
### Provide a list of related PRs _(if any)_
N/A
* add-type-from-cadl-azure-core
* add change log and format fix
* put paged into core-paging and lro header into core-lro
* fix format
* change to unreleased.
* Update CHANGELOG.md
* move model into http folder
* update api.md
* use cause
* use named exports
* resolve comments
* revert the core-lro change
* resolve comments
* Do not append customized api-version if url already has one e.g LRO/paging URL returned by the service
* Update format issue
* Fix test cases
* Bump a new version
* Update beta 10 version
* Update lock file
* Resolve conflict
* Update apiVersionPolicy.ts
* Merge into main branch
* Update test cases
* Fix lint errors
* Add feature to allow keep url apiVersion in policy
* Revert change
* Update pnpm lock file
* Update lints error
* Update file
* Update pnpm-lock
- eslint to ^8.0.0
- @types/eslint to ~8.4.0
- @typescript-eslint plugins to ~5.22.0
* Fix broken test because of class property node type changes. Improve test a bit
to also verifying error line and column numbers
* Disable @typescript-eslint/no-invalid-this
After upgrading this rule reports more false positives. The following comment on the
github issue suggests that it doesn't work for some callbacks because it is just
a simple rule that doesn't do type analysis.
https://github.com/typescript-eslint/typescript-eslint/issues/3620#issuecomment-876810901
* Fix linter issues after upgrading the plugins in eslint-plugin-azure-sdk. Also upgrade eslint version in the impacted packages
* Support the skipURLEncode option at query parameter
* Support the skipUrlEncoding option at query parameter level
* Fix the format errors
* Update comments
### Packages impacted by this PR
@azure-rest/core-client
### Issues associated with this PR
N/A
### Describe the problem that is addressed by this PR
This PR introduces a way for RLC customers to get a response body as raw streams
### What are the possible designs available to address the problem? If there are more than one possible design, why was the one in this PR chosen?
There are 2 additional options that were explored:
1. Passing an option to request options i.e. (client.path("/foo").get({responseAsStream: true});
2. Creating a helper function to get the stream i.e. `responseAsStream(client.path("/foo").get)`
However the selected approach feels more natural and friendly to work with
The following code will send the request and load the response body in memory:
```typescript
await client.path("/foo").get();
```
However if we don't `await` (or call then) directly on the method, we can also call 2 additional function `asNodeStream()` or `asBrowserStream()`
```typescript
await client.path("/foo").get().asNodeStream();
await client.path("/foo").get().asBrowserStream();
```
This will give you the raw streams to work with. It is important to note that `await client.path("/foo").get().asNodeStream();` only triggers a single request.
More details about the approach can be found here: https://gist.github.com/joheredi/124ce6d413901016894549b935657d32
Here's a video that shows the user experience
### Are there test cases added in this PR? _(If not, why?)_
Yes, added Node and Browser specific tests.
### Provide a list of related PRs _(if any)_
N/A
### Command used to generate this PR:**_(Applicable only to SDK release request PRs)_
N/A
### Checklists
- [x] Added impacted package name to the issue description
- [x] Does this PR needs any fixes in the SDK Generator?** _(If so, create an Issue in the [Autorest/typescript](https://github.com/Azure/autorest.typescript) repository and link it here)_
- [ ] Added a changelog (if necessary)
Thanks to #19530 we have a new HttpClient that uses Fetch. Currently, we can't make it the default because of recorded tests. However, we'd like folks to be able to try it out, which this PR makes possible.
The solution here is for tests that are dependent on XHR to pass in a custom HttpClient to allow the previous recordings to be used until we can migrate those packages to the new recorder.
This PR adds better handling for Binary and FormData for RestClients the main changes are:
- Move injecting api-version qsp to a pipeline policy to be more robust
- Logic to identify binary response content based on well known content-types
- Add a request option to explicitly tell core-client-rest to handle response a binary regardless of the content-type. This is useful for non-common content-types.
- Pack binary responses into Uint8Array
- Allow users providing Binary content for request body as Uint8Array or string
- Support form-data using the same body property. Internally we detect `content-type: multipart/form-data` and pass it to core-rest-pipeline as `request.formData`
* Multiple media type handling
* Add Template for path
* update api-extractor
* Add comments to Resource interface
* Revert path type changes
* Add comment about path type
* Omit lint check for Function type
* rebase main
* Revert confidential-ledger dependency bump
* make core rest client work with null and add encoding options
* adding test
* adding test
* use enableUrlEncoding instead
* change to skipUrlEncoding
* add change log
* update dependencies
* upate format
* update according comments
* update format
* change back dependencies
* update pnpm-lock
* resolve ci failure
Maor Leger
Jeremy Meng
Timo van Veenendaal
Matthew Podwysocki
Jeremy Meng
Ihor Shnaider
Minh-Anh Phan
Qiaoqiao Zhang
Deyaaeldeen Almahallawi
Jeff Fisher
Jose Manuel Heredia Hidalgo
Mary Gao
Daniel Getu
Harsha Nalluru
