Notable:
- Typescript 5.6: iterator functions and more
- typescript-eslint 8: new rules, breaking change to some other, found a
few bugs/test not actually testing
- eslint 9: new rules
- removed deprecation/deprecation plugin as typescript eslint has rule
for it now(and updated) many places where it wasn't reporting correctly
For a TypeSpec beginner, it may be difficult to understand how to
configure or format tspconfig.yaml to tweak the different options
available. Adding a basic example should help folks get started.
New pr from this branch as it had some weird docusaurus issue not
reproducable anywhere else and just changing branch fixes it somehow
https://github.com/microsoft/typespec/pull/3934
Notable:
- vitest: 2.x
- prettier update that does a minor formatting change by adding
parentheses in some ternary expression
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>
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>
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>
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
- 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)
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>
There is a bug in the protobuf emitter currently where we use the base
name of a template when emitting corresponding models. This patch adds
support for extracting an instance name, using friendlyName if it is
available or otherwise constructing a name by prepending the name of the
argument types to the template's name.
Closes#2857
---------
Co-authored-by: Will Temple <will@wtemple.net>
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
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
Copying changes from https://github.com/Azure/typespec-azure/pull/3731/
Note: I added the following files as they were missing but the
corresponding `.mocharc.yaml` files already exist:
- packages/protobuf/mocha.reporter.config.json
- packages/samples/mocha.reporter.config.json
- packages/typespec-vscode/mocha.reporter.config.json
This change preserves `@doc` comments when emitting protobuf schemas. We
convert the protobuf documentation comments into a format that will feel
familiar to Protobuf developers and that Protobuf tooling will be able
to parse. I've never used a documentation generator with Protobuf, but I
made sure it works with pseudomuto/protoc-gen-doc, as that seems to be
the most recommended community project for doc generation. I also made
sure that the protoc Java compiler emits readable documentation based on
the example spec in the tests.
The rules for comments are:
- On _field_ and _enum variant_ declarations, we will emit a trailing
`//` comment if the length of the line overall will not be longer than
80 characters.
- In all other cases, we will emit a block of `//` comments aligned with
the beginning of the declaration.
Closes#1878
---------
Co-authored-by: Will Temple <will@wtemple.net>
Co-authored-by: Timothee Guerin <tiguerin@microsoft.com>
fix#2084
When a diagnostic target a type/node instead of reporting the error on
the whole type spamming the IDE or terminal with a large warning/error
we only highlight that type id instead.
This is the behavior we can see in typescript/eslint. When the
error/warning is meant to target an interface/function, etc. it will
only highlight the name when able.
This PR tweaks the way that models are included in output specifications
when they are not referenced by operations and adds an option for
controlling this behavior.
The option is `omit-unreachable-types` after the OpenAPI v3 emitter
which uses the same name, and the behavior in the protobuf emitter is
similar. If a message is expliclty decorated with `@message` or is
referenced direclty or indirectly by an operation/method, it will be
emitted. Otherwise, it will be emitted if (1) it is a direct child of a
`package` namespace AND (2) ALL of its fields are annotated with
`@field` AND (3) the `omit-unreachable-types` option is not set to true.
Closes#1879
---------
Co-authored-by: Will Temple <will@wtemple.net>
Timothee Guerin
Christopher Radek
Michelle
Allen Zhang
Will Temple
Vitalii Kryvenko
Mark Cowlishaw
Alexander Batishchev