## Backgrounds
I first reported this on discussion: #3194
## Issue description
There is a code sample
[here](https://typespec.io/docs/language-basics/namespaces#using-namespaces)
describing the scope of an item introduced by `using`.
```ts
namespace One {
model A {}
}
namespace Two {
using One;
alias B = A; // This is valid
}
alias C = One.A; // This is not valid
alias C = Two.B; // This is valid
```
## Expected result
The code should failed to compile because of `One.A`.
## Actual result
It compiles without any warning.
## How to fix
It appears that the original intent was to show that accessing an item
introduced with `using` outside the scope of `using` is not possible. In
this code, the 'invalid accessing' is `Two.A`.
## Changes
- change `One.A` to `Two.A`
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>
`@server` works to provide values for the `servers` object, as is
documented elsewhere in the same files. This PR updates the table to
reflect that. Closes#3071.
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>
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>
Closes#2718
This change adds support for an optional message that emitters may use
to communicate the context of a pattern validation error.
I also added some baseline tests for `@pattern` since there were none in
decorators.spec.ts.
---------
Co-authored-by: Will Temple <will@wtemple.net>
Co-authored-by: Timothee Guerin <timothee.guerin@outlook.com>
Add vitest ui package and `test:ui` command to popup the vitest UI
https://vitest.dev/guide/ui
Import the common vitest config from the workspace so each package
doesn't need to define all of it.
Added `watchExclude: []` to the common config to preven vitest from
excluding dist and node_modules folder which is required so it can auto
rerun the test on when a dependency (monorepo dep) rebuilds
Added debug config to debug the current test. As the vitest extensions
is quite unreliable this should help
Add a new library template with:
- `@alernateName` decorator with some custom diagnostics and tests for
it.
- a linter rule and 2 rulesets(`recommended` and `all`)
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
fix#2301
## Deteach the linter from `$lib`
Having the linter rules defined in `$lib` caused this circular reference
where the rules would call to some accessor that needed the $lib
diagnostics.
With this we keep $lib as manifest and helper functions only.
## Add state key declaration
```ts
export const internalLib = createTypeSpecLibrary({
state: {
authentication: { description: "State for the @auth decorator" },
header: { description: "State for the @header decorator" },
...
});
// use with StateKeys.authentication
```
## Add 3 new helper functions to be able to change the casing in
templates
```
naming.pascalCase
naming.camelCase
naming.kebabCase
```
## Update the `emitter-ts` to interpolate the emitter name
## Add snapshot test for templates
This way we can see what instantiating the template does at review time
and catch errors that wouldn't make the template crash the e2e test but
would still not be optimal
## Add a new template for scaffolding an emitter
`emitter-ts` template setup the following:
- basic emitter files
- typescript
- test with node test runner with basic test and test host setup
- prettier
- linting with eslint
## Change to the init area
- Added a new `--template` cli option to allow selecting the template
without a prompt.
- Refactor to make it easier to test. **Note that none of the API is
exposed yet so its just for internal use.**
## Added e2e test for templates
Scafold the template and then run commands like `npm install`, `npm run
build`, `npm run test`, etc. to make sure everything is done correctly.
This is quite costly so might be worth separating in a different step
Implementation of named template arguments as described in #2340.
I added a new syntax node (TemplateArgument), and a cover grammar for
this node:
`<Expression> ('=' <Expression>)?`
Rather than ExpressionNode, the type of a template argument is now
`TemplateArgumentNode`.
If the `=` is parsed, we assert in the parser that the first Expression
must be a "bare identifier" (i.e. a TypeReference with `target:
Identifier`) and unwrap the identifier to produce a clean AST with
`name?: Identifier
Template arguments are evaluated in the order that they were declared,
not in the order they are specified in the instantiation. The new
template argument checker _replaces_ the previous one, and it performs
normalization of argument order and typechecking of template arguments
all in one pass.
TODO:
- [x] Review templates across core libraries to ensure that template
arguments have good names.
- [x] Documentation of new behavior in website.
- [x] Semantic/tmlanguage colorization of tokens.
- [x] Validate that the AST printer produces the correct text for the
new template argument nodes and that the output is well-formatted.
- [x] Completion of template argument names in argument position.
- [x] Hover context on template argument names in instantiation.
Closes#2340
---------
Co-authored-by: Will Temple <will@wtemple.net>
Co-authored-by: Mark Cowlishaw <markcowl@microsoft.com>
Co-authored-by: Timothee Guerin <timothee.guerin@outlook.com>