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.
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>
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
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>
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>
Fixes https://github.com/microsoft/typespec/issues/3262
This adds a new confirmation prompt to `tsp init` to generate a
.gitignore file. Defaults to yes (true).
---------
Co-authored-by: Christopher Radek <Christopher.Radek@microsoft.com>
fix#3038
This PR updates the `@typespec/openapi3` package to support converting
OpenAPI3 specs to TypeSpec.
## Example usage:
1. `npm install @typespec/openapi3`
2. `npx openapi3-to-tsp compile --output-dir ./tsp-output
/path/to/openapi-yaml-or-json`
## What's supported
- Parse OpenAPI3 specs in yml/json formats (via 3rd party package)
- Generates file namespace based on OpenAPI3 service name
- Populates `@info` decorator with OpenAPI3 service info
- Converts `#/components/schemas` into TypeSpec models/scalars.
- Converts `#/components/parameters` into TypeSpec models/model
properties as appropriate.
- Generates a response model for every operation/statusCode/contentType
combination.
- Operation tags
- Generates TypeSpec operations with routes/Http Method decorators
- Generates docs/extension decorators
- Most schema decorators
- Model inheritance via `allOf`
- Discriminators
## What's not supported (yet)
- auth
- deprecated directive
- combining multiple versions of an OpenAPI3-defined service into a
single TypeSpec project
- converting `#/components/requestBodies` and `#/components/responses`
into models - TypeSpec doesn't seem to generate these and I didn't find
examples in the wild where they were defined _and_ actually used so
deprioritized.
- emitting warnings/FIXMEs for unexpected/unsupported scenarios
- Probably a lot more that I'm still discovering
## Notes
When going through the TypeSpec -> OpenAPI3 -> TypeSpec loop, the
generated TypeSpec is going to be larger than the original. The biggest
contribution towards this is because I'm currently generating a model
for every possible response on every operation.
I can definitely pare this down with some simple heuristics that take
into account what default statusCode/contentTypes are, and extract the
referenced body type directly in the operation's return signature. I can
also eliminate the `@get` decorators, `@route("/")` routes, and likely
use some of the response models provided by TypeSpec.Http.
However - if I'm using this tool to convert from OpenAPI3 to TypeSpec -
I thought it might be preferable to be more explicit in the generated
output so there's no mystery on how things actually get defined. Will be
interested in feedback on this.
## Testing
For tests, I generate TypeSpec files for a number of OpenAPI3 specs.
Most of the OpenAPI3 specs I generated from our TypeSpec samples
packages. Then I'm able to compare the generated TypeSpec to the
corresponding original TypeSpec file. I've also been diffing the
OpenAPI3 specs generated from the original and generated TypeSpec files
<- these are what typically show no changes outside of known unsupported
conversions (e.g. auth).
---------
Co-authored-by: Christopher Radek <Christopher.Radek@microsoft.com>
fix https://github.com/microsoft/typespec/issues/3397
Problem with calling `getAssetEmitter` is it create an asset emitter
with the instance of the compiler used in the compilation and not the
instance of the compiler defined in the type emitter necessarly. This
cause issue with `instanceof` checks which are then not the exact same
class as its loaded form different instance of the compiler
Calling `createAssetEmitter` solve the issue because it is imported in
teh context of the emitter package and will use the emitter package
version
Error.captureStackTrace is used to get stacktrace for tracing details,
but it's not supported in some browser like firefox, so add handling for
it. thanks.
---------
Co-authored-by: Timothee Guerin <timothee.guerin@outlook.com>
fix#3504
When unsuitable types are specified in the model property, the invalid
code location is now reported instead of throwing an error.
When compiling the following tsp file, it is reported as follows
```tsp
interface TestInterface1 {
get1(prop: TestInterface1): TestInterface1;
}
```
```
Diagnostics were reported during compilation:
/projects/typespec/packages/samples/scratch/main.tsp:2:8 - error @typespec/openapi3/invalid-model-property: 'Interface' cannot be specified as a model property.
> 2 | get1(prop: TestInterface1): TestInterface1;
| ^^^^
Found 1 error.
```
---------
Co-authored-by: Timothee Guerin <tiguerin@microsoft.com>
Co-authored-by: Timothee Guerin <timothee.guerin@outlook.com>
Closes#3534Closes#3556
This PR adds cross-package resolution in some cases where it was
missing.
In the case of operation inputs, missing effective model type
calculation was causing some input types not to be resolved to external
packages.
In the case of map value types, the calculation of the right hand side
type did not correctly account for the possibility of the type being in
another package, and it now uses the same machinery as other type
references to instrument imports and cross-package references.
The existing scenario test has been extended to prevent regressions and
also extended to test arrays for good measure, though those were working
as expected.
---------
Co-authored-by: Will Temple <will@wtemple.net>
Co-authored-by: Timothee Guerin <tiguerin@microsoft.com>
fix #1016
Format multi lines string
```
@doc(
"""
multi line
do
${"abc"}
"""
)
@doc("""
def
""")
model Foo {}
alias T = """
abc
def ${"abc"}
ghi
""";
```
formats to
```
@doc("""
multi line
do
${"abc"}
""")
@doc("""
def
""")
model Foo {}
alias T = """
abc
def ${"abc"}
ghi
""";
```
Related to #3374, this is an implementation of escaping characters in
doc comments, such as the `@` symbol.
---------
Co-authored-by: Timothee Guerin <timothee.guerin@outlook.com>
Co-authored-by: Timothee Guerin <tiguerin@microsoft.com>
Issue is that we were returning before the hook declarations when there
was no output files which cause react to crash due to number of hook
running changing
This cover the case where you have a package only used to create ruleset
but doesn't have any rules.
---------
Co-authored-by: Mark Cowlishaw <markcowl@microsoft.com>
resolve#3046
[Playground](https://cadlplayground.z22.web.core.windows.net/prs/3342/)
Add the following:
- `@multipartBody` decorator
- `File` type
- `HttpPart<Type, Options>` type
Had to do a decent amount of refactoring to be able to reuse the body
parsing, this result in a much cleaner resolution of the body and other
metadata properties across request, response and metadata.
The way it works now is instead of calling `gatherMetadata` that would
just get the properties that are metadata but also ones with `@body` and
`@bodyRoot` we now call a `resolveHtpProperties`, this does the same
resolution in term of filtering properties but it also figure out what
is the kind of property in the concept of http(header, query, body,
etc.) this leaves the error resolution to this function for duplicate
annotations.
What is nice is now we don't need to keep asking oh is this a query or a
header or a body we can just check the kind of `HttpProperty`
also resolve#1311
## Issue Description
There is a example of `TypeSpec.http.@statusCode`
[here](https://typespec.io/docs/next/libraries/http/reference/decorators#@TypeSpec.Http.statusCode).
However, the property name is missing in this example. Due to this, the
code did not work as expected.
```
op read(): {@statusCode: 200, @body pet: Pet}
op create(): {@statusCode: 201 | 202}
```
Instead, specifying the property name as follows made it work correctly:
```
op read(): {
@statusCode _: 200;
@body pet: Widget;
};
op create(): {
@statusCode _: 201 | 202;
};
```
## Fix Description
- Corrected examples of `TypeSpec.http.@statusCode` in the reference and
documentation.
---------
Co-authored-by: Timothee Guerin <tiguerin@microsoft.com>
Co-authored-by: Timothee Guerin <timothee.guerin@outlook.com>
Co-authored-by: Mark Cowlishaw <markcowl@microsoft.com>
fix#3447
Fixed a few issues with circular references in the JSON Schema emitter
and emitter framework:
* The emitter framework wouldn't restore context correctly when directly
emitting a type reference to a type with a circular reference.
* The JSON Schema emitter did not handle circular references involving
non-JSON Schema types.
* The JSON Schema emitter would create an infinite loop when circular
references needed to be put into $defs.
---------
Co-authored-by: Timothee Guerin <timothee.guerin@outlook.com>
Fixes#3369 by changing how types are bundled. In particular, when a
type is not a JSON Schema type, we never create a root schema for it.
Instead, it is inlined into the defs of any schema which references it,
and referenced using a JSON pointer. This PR makes bundling have
essentially no impact on emitted schemas, and is merely a way to bundle
them into a single file.
The approach is as follows:
* When a type references another type outside a JSON Schema namespace,
include the referenced type under $defs:
* Such referenced types do not have a $id or $schema field
* Such referenced types are referenced via JSON pointers not ids
* Bundling does not alter the bundled schemas or introduce new root
schemas. This changes two things from what we do today:
* The `$id` of the bundled schemas now includes the file path as it does
for non-bundled schemas (whereas before it was just the type name)
* non-JSON Schema types do not get $defs in the bundle, so the bundle
has the same root schemas as would be written to disk when not bundling.
In terms of implementation, the basic approach is to not handle bundling
via the emitter framework source files. Instead, we always create source
files for root schemas, and inline the necessary defs as we did before
(but now using JSON pointers). Then when we're about to write source
files, if we're bundling we assemble the bundle and emit that single
file, otherwise we emit each source file that contains a root schema.
Todo:
* [ ] Validate that the bundled schemas continue to work with ajv.
* [ ] Cleanups
---------
Co-authored-by: Vitalii Kryvenko <gersoh3@gmail.com>
Versioning library is a big mess of things all into one file, this makes
it hard to contribute. Did this originally because I was going to deal
with multiple madeRequired and madeOptional over time but that will be
done later but finished the cleanup anyway.
Split the versioning.ts into multiple separate logical files:
- `decorators.ts`: Contains all the versioning decorators and accessor
- `internal-projection-functions.ts`: Contains implementation of the
helper function used inside the versioning projection(not meant for
external use)
- `projection.ts`: Contains the projection building functions
- `versioning.ts`: Contains the various versioning computation
function(timeline, etc.)
This makes it clearer of what is supposed to be public apis vs internal,
waht is just mean for decorator, projection, etc.
Fixes#3210
While the issue was for model properties, it also applies to interfaces,
so tests are included for both.
---------
Co-authored-by: Timothee Guerin <timothee.guerin@outlook.com>
Using rollup wasn't working super well when running in watch mode with
the playground-website package refresh and needed some restart.
Unfortunatelly can't seem to find a good way to just run `pnpm start` in
`/playground-website` and have that working so still have to do `pnpm
watch` in `/playground` as well.
Fixes#3391
Also refactored a minor problem of using a deprecated reexport of
`DuplicateTracker`, not it's referenced from `@typespec/compiler/utils`
directly, and another small typo.
---------
Co-authored-by: Timothee Guerin <timothee.guerin@outlook.com>
Co-authored-by: Timothee Guerin <tiguerin@microsoft.com>
Fixes#3370.
This also updates the generated documentation and typescript code to fix
lack of indentation on existing fenced blocks in this repo.
---------
Co-authored-by: Timothee Guerin <timothee.guerin@outlook.com>
Seems like we also need a `vitest.config.ts` at the root of the
workspace to override the `watchExclude` setting otherwise `dist` and
`node_modules` are still excluded and everytime require a refresh of the
vitest UI or restarting the watch. Only thing that was working is if you
modified the test files or modified imported files directly from the
test
add following feature
1. support completion when user typing model expression as decorator
argument value
2. support completion for extended model
3. support showing decorator model argument prop information when
hovering on model expression as decorator argument value
closes#3130, closes#2228, closes#1956
---------
Co-authored-by: Timothee Guerin <timothee.guerin@outlook.com>
They cause vitest to not be happy randomly. This is only a problem with
non type import so adding `type` helps finding which ones are a real
problem
Use madge with this command to find them
```
npx madge --circular --extensions ts ./src/
```
with this config
```
{
"detectiveOptions": {
"ts": {
"skipTypeImports": true,
"skipAsyncImports": true
}
}
}
```
Hopefully I got all the places I needed to get and added enough tests.
My methodology was pretty much "Look at what madeOptional does, and do
the opposite"
Closes#2731
---------
Co-authored-by: Timothee Guerin <tiguerin@microsoft.com>
Co-authored-by: Timothee Guerin <timothee.guerin@outlook.com>
resolves#2046
[Playround](https://cadlplayground.z22.web.core.windows.net/prs/3022/)
Add the new syntax for object literals using `#{`. For this first
version an object literal can only contain other object literal and
other literals(string, number, boolean))
## Values axioms
1. `alias` always produces a type. If you attempt to alias a value, you
get an error.
2. A string template produces a string template type if all
substitutions are types, and a value if all substitutions are numeric,
boolean, or string values. A mixture of types and values is an error.
3. The string literal syntax always results in a string literal type
4. A string literal type may be passed as a string value when the
signature expects a value. When the signature expects either a string
literal type or a string value, it is passed as a string value.
5. A string template type can be passed as a string value when all its
substitutions are string literal types.
## Breaking change
### Removal of the `ValueType` replacement with `MixedConstraint`
This shouldn't affect anyone as you were only exposed to this if you
digged into the template parameter and looked at the constraint
## Deprecation
## Using a tuple instead of a tuple literal
- ✅ still work
- emit a warning
<img width="1013" alt="image"
src="https://github.com/microsoft/typespec/assets/1031227/ab05359a-5ed9-4a27-a8d1-f40d1e21766f">
- provide a codefix
<img width="312" alt="image"
src="https://github.com/microsoft/typespec/assets/1031227/5ef93bdf-665f-4445-a6b2-62475efe8c16">
## Using a model expression instead of an object literal
This technically didn't work before(different from above where tuple was
used as a value) but allow this will allow us to convert most of our
decorators to use `valueof` without being breaking
## Old decorator marshalling
If a library had a decorator with `valueof` one of those types
`numeric`, `int64`, `uint64`, `integer`, `float`, `decimal`,
`decimal128`, `null` it used to marshall those as JS `number` and
`NullType` for `null`. With the introduction of values we have a new
marshalling logic which will marshall those numeric types as `Numeric`
and the others will remain numbers. `null` will also get marshalled as
`null`.
For now this is an opt-in behavior with a warning on decorators not
opt-in having a parameter with a constraint from the list above.
Example:
```
extern dec multipleOf(target: numeric | Reflection.ModelProperty, value: valueof numeric);
```
Will now emit a deprecated warning because `value` is of type `valueof
string` which would marshall to `Numeric` under the new logic but as
`number` previously.
To opt-in you can add the following to your library
```ts
export const $flags = defineModuleFlags({
decoratorArgMarshalling: "value",
});
```
---------
Co-authored-by: Brian Terlson <brian.terlson@microsoft.com>
Co-authored-by: Mark Cowlishaw <markcowl@microsoft.com>
Node `fetch` built-in function is now out of experimental since node
`18.13.0` this allows us to not have some partial implementation and get
rid of an external dependency
This is a breakage due to a breaking change in node's latest incremental
version. (See https://github.com/nodejs/node/issues/52554 for
background). Adding shell: true fixes this.
Fixes#3242.
---------
Co-authored-by: Timothee Guerin <timothee.guerin@outlook.com>
fix#3211
Problem was we were checking the decorator declaration passing the
`mapper` this mean the checker was thinking we were defining this
decorator declaration in a template instance(which is not possible)
This resulted in the argument marshaling to not happen as it will only
happen when there is a valueof constraint
fix [#3102](https://github.com/microsoft/typespec/issues/3102)
Problem was that when following redirect we need to explicitly close the
response watch otherwise we always await on it
However I switched to using `follow-redirects` library that will more
safely handle redirect for us.(e.g. max redirects)
With node 22 the fetch api should not be experimental anymore so we
could potentially migrate to it next year when node 20 is out of support
resolves [#2818](https://github.com/microsoft/typespec/issues/2818)
Add a new `sourceModels` property that keeps track of models used to
construct it. `sourceModels` is an array of a new `SoruceModel` object
which contains metadata on how the model was used:
- is: `model A is B`
- spread: `model A {...B}`
- intersection: `alias A = B & C`
fix https://github.com/microsoft/typespec/issues/3171
Currently the `--nostdlib` option is just useless, here splitting the
intrinsic types from the rest of the std lib.
Intrinsic types will always be loaded regardless of what `nostdlib`
says.
Being able to disable that can be useful in the compiler test to not be
polluted by some extra elements.
The `dumpAst` helper was imported from `parser.test.ts` in 3 other files
which caused vitest to randomly run the parser.test.ts tests(371 tests)
extra times. It wasn't consitent which is how I caught it the number of
test passed by vitest changed significantly from one run to the other
Notable:
- vitest `1.5.0` which solves some issues with running in the extension
- remove `sinon` from compiler which is not needed anymore as vitest
provide spies built-in
This was causing errors in doing things like this
```ts
model Info {
age: int32;
...Record<string>;
}
model Bar<T extends Info> {}
model Test {
t: Bar<{
age: 123;
other: "abc";
}>;
}
```
Add xml library following the approved design.
fix#2970
Only minor change was inverting the parmaeters for `@ns(namespace,
prefix` instead of `@namespace(prefix, namespace)` which makes it
clearer with the other overload `@ns(namespace: EnumMember)`
---------
Co-authored-by: Mark Cowlishaw <markcowl@microsoft.com>
Co-authored-by: Brian Terlson <brian.terlson@microsoft.com>
Adding new `Numeric` data structure for the value world.
This PR doesn't export it so it won't be usable just yet but this
sparate this quite complex entity from the rest of the value world PR
- Use corepack to install pnpm: Faster and respect the pnpm version set
in package.json instead of having another place to keep up to date
- dependency cache
- upgrade to new code coverage task
- Move all consitency check to independent github action workflow(Makes
it easier to see which one failed immediately without having to open
devops and dig into the steps)
swagger-ui-react pull in all the swagger ui dependencies which is a bit
anyoing as they are mostly optional and with pnpm requires you to build
native dependencies.
Setup a workaround for the fact that vitest(vite underneath) doesn't
ever want to reload files in the outDir
https://github.com/vitest-dev/vitest/issues/5429
as the outDir isn't actually used in vitest(as far as I understand) this
is just an ok workaround.
fix#3073
This still doesn't provide an optimal experience as the error shows up
on the void type instead of where it is referenced but solving that is
that long standing issue about tracing back where an error should be
fix [#2946](https://github.com/microsoft/typespec/issues/2946)
Problem was that in the projector were were calling to this helper to
see if that was a type that we should finish but it was missing the
union case causing union template declaration from being finished in the
projector and then being shown as finished type in the semantic
navigator and crashing openapi3 emitter.
fix#2217
This isn't fully accurate as it is saying in openapi3 that it can be
anything and `null` but this solve a crash, we could consider adding a
warning
---------
Co-authored-by: Mark Cowlishaw <markcowl@microsoft.com>
Note this is added to `tspd` which is not published yet so this can be
iterated over without any issues.
Adds a decorator signature generator. Generates 2 files:
- `<namespace>.ts` : Contains the decorator signatures that can be
imported and when declaring the decorators functions
- `<namespace>.ts-test.ts`: Contains some test using typescript type
system to make sure the package does reexport the right `$<name>` for
each decorator
---------
Co-authored-by: Brian Terlson <brian.terlson@microsoft.com>
Co-authored-by: Mario Guerra <85648637+mario-guerra@users.noreply.github.com>
Co-authored-by: Libba Lawrence <llawrence@microsoft.com>
Co-authored-by: Allen Zhang <allenzhang@live.com>
Co-authored-by: Brian Terlson <brian.terlson@microsoft.com>
fix [#2821](https://github.com/microsoft/typespec/issues/2821)
## Deprecate `@service({version`
Using this property will emit a deprecation warning
## Cover everything with `@OpenAPI.info`
Makes sure all the properties allowed on the `info` object of openapi
specification can also be provided in `@info`. The properties will
either override other ways of specifying those previously or be the only
way.
- `@info({description` would override `@doc` on service namespace
- `@info({summary` would override `@summary` on service namespace
- `@info({title` would override `@service({title}` on service namespace
fix [#2925](https://github.com/microsoft/typespec/issues/2925)
Stop emitting the error if there is a shared route and a non shared
route on a different verb.
Also improve the error:
- change message to be a little more clear
- emit the error on every offending operation not just the first one we
find an duplicate
---------
Co-authored-by: Brian Terlson <brian.terlson@microsoft.com>
fix#2787
having multiple has no effect, the latest value will override the
previous ones so there is no reason to use `@useAuth` twice on the same
node
---------
Co-authored-by: Brian Terlson <brian.terlson@microsoft.com>
PR added support for it but we need to update the docs to explain the
new feature.
---------
Co-authored-by: Brian Terlson <brian.terlson@microsoft.com>
Hi! 🖖🏻
This PR resolves#2624 by implementing the [design
doc](https://gist.github.com/timotheeguerin/56690786e61a436710dd647de9febc0f),
but in its initial form:
- `@useAuth` can now be applied not only to service namespace, but to
interfaces and operations as well. Its arguments override all
authentication, which was set for enclosing scopes.
- OAuth2 scopes can now be set at operation level (though, the code
doing this in OpenAPI emitter is a bit clunky).
- New `NoAuth` authentication option allows to declare optional
authentication (`NoAuth | AnyOtherAuth`) or override authentication to
none in nested scopes.
This implementation does not introduce new `@authScopes` decorator as
design doc comments suggest, and here's why:
1. It does not compose well with `@useAuth` at operation level. For
example
```
...
@useAuth(BasicAuth)
@authScopes(MyOauth2, ["read"])
op gogo(): void
```
Should that be equivalent to `BasicAuth | MyOauth2`, or to `[BasicAuth,
MyOauth2]`?
2. Introducing new decorator would increase complexity, but (imho) it
would not reduce the amount of boilerplate:
```
alias MyOAuth2 = OAuth2Auth<{ ... }>;
@useAuth(MyOAuth2)
@authAcopes(MyOauth2, ["read"])
@service
namepsace Foo;
```
vs
```
model MyOAuth2Flow<T extends string[]> { ... };
alias MyOauth2<T extends string[]> = Oauth2Auth<[MyOauth2Flow[T]]>
@useAuth(MyOAuth2<["read"]>)
@service
namepsace Foo
```
I would be happy to hear any feedback and apply suggested changes.
And thanks for a convenient development setup and thorough test
coverage!
---------
Co-authored-by: Timothee Guerin <timothee.guerin@outlook.com>
This function is useful when you want to work with the OpenAPI 3
directly, or don't want to write it to disk for some reason.
---------
Co-authored-by: Timothee Guerin <timothee.guerin@outlook.com>
Provide a new exports `/utils` where we can export utils that are
commonly used in libraries and emitters but not tied to typespec
directly(deepClone, deepEquals, etc.)
Since we moved to `workspace:~` instead of `workspace:~x.y.z` for
dependency when building pr artifact it is repalced with the actual
version which in pr case is `x.y.z-pr.{prnumber}.{buildid}` and this
cause installation conflict
Timothee Guerin
Christopher Radek
Sarangan Rajamanickam
Laurent Mazuel
Will Temple
Irvine Sunday
Sylvain Bruyère
Justin
Yuchao Yan
Rodge Fu
Allen Zhang
shiron-dev
Brian Terlson
Reinier Hartog
☃ Elliot Shepherd
Travis Prescott
もっちー
Vitalii Kryvenko
Jim Borden
LadyCailin
m-nash
iscai-msft
Vasil Markoukin
Ikko Eltociear Ashimine