Idea that could be expanded/exposed to other libraries in the future.
Define clearly how to access a certain state key.
Doing that now as for paging there is a lot of decorators that are added
and that will simplify.
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>
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
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>
Get rid of mocha and upgrade to vitest which is a more modern
alternative providing, watch, direct typescript compilation out of the
box, expect library and more.
Advantage over mocha:
- Much better cli
- watch mode
- better diff
- Better extension:
- tree organization for files too (not everything flattened)
- update in real time the test(no more need to refresh manually to
discover where are the tests)
- just a little buggy
- Compiles typescript directly
- provides more expectation apis(like jest)
Cons over mocha:
- Slower(about 2x) but that means we don't need to build the test as
part of build which would speed up that part(not as much as is lost)
Todo:
- typespec-azure migration
Timothee Guerin
Will Temple