Fixes#3810 and replaces #3808
This PR does 2 things:
1. Groups operations/models into namespaces based on the dots in their
schema names/operationIds.
2. Escapes invalid identifiers by surrounding them with backticks.
---------
Co-authored-by: Christopher Radek <Christopher.Radek@microsoft.com>
fix#2276 As the design for a dedicated `@instanceName` was not approved
due to the concern that we should maybe have a more generic `@name`
decorator that handle template I am just fixing this very anyoing carry
over that requires using `@friendlyName` in all derived models when it
is used upstream.
This is technically a breaking change as if you used to have
```
@friendlyName("Abc{T}", T)
model Foo<T> {}
model Bar is Foo<string>
```
it would have created a model called `Abcstring` instead of `Bar`
---------
Co-authored-by: Mark Cowlishaw <markcowl@microsoft.com>
Fixes#3835
`tsp-openapi3` will no longer automatically attempt to wrap
documentation strings based on maximum column width.
It will still honor any line breaks that exist in the original
documentation when generating doc strings.
---------
Co-authored-by: Christopher Radek <Christopher.Radek@microsoft.com>
Per the requirement in Issue:
https://github.com/microsoft/typespec/issues/3632, the dependency of
`@typespec/compiler` has to be moved from `dependencies` to
`peerDependencies`. This PR moves the dependency.
Some snippets are not adding the return types explicitly to the return
expression, this PR adds them.
---------
Co-authored-by: m-nash <64171366+m-nash@users.noreply.github.com>
This work-in-progress PR tracks merging the JavaScript server code
generator to the TypeSpec repository.
The JavaScript server code generator creates HTTP bindings for TypeSpec
HTTP services and exposes them for binding either to the Node.js http
server directly, or to an Express.js app as middleware.
Closes#3215
---------
Co-authored-by: Will Temple <will@wtemple.net>
We were all doing mocking slightly differently. I created a common
helper to mock the plugin and provide some functionality to pass in
behaviors that we want to change on a per test basis. I will make a
follow up PR to update mgc.cm to follow the same pattern.
Closes#3539
This change disallows overriding a required inherited property with an
optional property.
This error does not take precedence over regular property assignability
rules. In case the property _both_ is optional when the overridden
property is required _and_ has a non-assignable type, both errors will
be reported.
---------
Co-authored-by: Will Temple <will@wtemple.net>
This is something that is quite useful for any external tool that want
to write some typespec code(Openapi3 to tsp converter for example or api
view)
Edit: actually that was already exported as that exact name directly
from the formatter. This then just adds tests
- export more apis from http-client-csharp library so that those api can
be used in follow-up emitter.
- change NetEmitterOptions to interface: it can be extended; consistent
with others e.g. SdkEmitterOptions; it can used as partial scenario to
add more fields which may more suitable for plugin framework.
This updates the `tsp-openapi3` CLI so that it emits `main.tsp` even
when the formatter detects an issue. The CLI will still throw the error
after it is done emitting the file.
The `convertOpenAPI3Document` function used by the website does not
throw on formatter errors - the playground will highlight any TSP errors
already.
Playground example with bad emission:
---------
Co-authored-by: Christopher Radek <Christopher.Radek@microsoft.com>
A recent break in storage blob SDK corrupted the uploading of certain
files https://github.com/Azure/azure-sdk-for-js/issues/30138 when using
the `upload(text, length)` method. Switching to converting to a buffer
and uploading fixes the issue.
Fixes#3692
In the practice, we usually need to keep tracking the property-parameter
conversion
For instance, when constructing the constructor of a model, we first
construct all the properties of the current model then building up the
ctors. And during building the ctors, we need to convert the properties
to parameters. And in the body of the ctor, we will need to assign the
parameters to the properties, but the code of building signature and
body are in different places, therefore we may lose track of the
conversion relationship therefore we will have to find them by names.
This PR adds the two-way references among `ParameterProvider`,
`PropertyProvider` and `FieldProvider`.
You can convert a property to a parameter by calling the
`PropertyProvider.Parameter`, and the constructed parameter will hold
the reference of the propety which constructs it.
Similarly you could do the same between fields and parameters.
In this way we could prevent that when building something, we will make
things up.
there is also a two-way reference between property and field, but this
is not a conversion, this is to track the field to be the "backing
field" of the property, and vice versa. We do not have a solid use case
for this yet, therefore this part is only prototyping, and if possible,
I could remove it from this PR and add it back later when we have a case
for it (such as the json merge patch case?).
---------
Co-authored-by: m-nash <64171366+m-nash@users.noreply.github.com>
Fixes https://github.com/microsoft/typespec/issues/3739
Previously, constructors and methods are both represented by
`MethodProvider`, which is quite inconvenience in some cases that we
want to get the `ReturnType` out from a method, we will have to cast the
`Signature` to `MethodSignature`.
A new type `ConstructorProvider` is introduced in this PR to represent
ctors only and now the `Signature` type is `MethodSignature` in
`MethodProvider` which only represents the normal methods.
Considering that ctors and methods are similar, we may add a common base
type to `MethodProvider` and `ConstructorProvider`, such as
`MethodBaseProvider` just like how `MethodSignature` and
`ConstructorSignature` do.
But currently I did not see any use case that requires to add ctors and
methods into the same list, therefore this PR does not add that, and we
could always add that part later.
---------
Co-authored-by: m-nash <64171366+m-nash@users.noreply.github.com>
1. Fix#3740
2. Add `IsNullable` to `PropertyWireInformation` so that downstream
could know whether we should check `null` when doing serialization.
Confirmed after this change, the core part of test code (like
serializing properties) now is exactly same as that in autorest.csharp.
(except some code structure thing like `WriteCore`)(except that in this
this repo there are several newly-added properties like
`FloatExtensibleEnumWithIntValue` which is not in autorest.csharp)
---------
Co-authored-by: Pan Shao <pashao@microsoft.com>
Co-authored-by: m-nash <64171366+m-nash@users.noreply.github.com>
Fixes https://github.com/microsoft/typespec/issues/3446
By adding support for extending namespace, we will be able to add
extensions to the OpenAPI `info` object via the new function -
`setNamespaceExtension(...)`
---------
Co-authored-by: Timothee Guerin <timothee.guerin@outlook.com>
Co-authored-by: Timothee Guerin <tiguerin@microsoft.com>
fix [#3647](https://github.com/microsoft/typespec/issues/3647)
With node 22 the --test needs a glob to find files to test. As the docs
a written the tests don't run or pass. This fixes it for me.
---------
Co-authored-by: Timothee Guerin <tiguerin@microsoft.com>
Christopher Radek
Timothee Guerin
Dapeng Zhang
JoshLove-msft
Mario Guerra
Sarangan Rajamanickam
Laurent Mazuel
Will Temple
m-nash
Jorge Rangel
Crystal YU
Pan Shao
Irvine Sunday
Sylvain Bruyère
Justin
Yuchao Yan