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
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
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>
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>
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>
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
fix [#2535](https://github.com/microsoft/typespec/issues/2535)
Converted most of the `throw error` to either:
- `compileAssert` if it is somethign that shouldn't happen
- `reportDiagnositc` if this is something actionable by the user
There is still 2 `throw error` as I'm not sure if those are things that
could happen or not. I'll leave them until someone maybe gets a crash
and we can then convert.
---------
Co-authored-by: Mark Cowlishaw <markcowl@microsoft.com>
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
Timothee Guerin
Allen Zhang
Brian Terlson
Vitalii Kryvenko
iscai-msft
Mark Cowlishaw
Will Temple
Alexander Batishchev
Travis Prescott