[POC] Create GraphQL Mutation engine #54
Draft
+29,160
−7,363
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
microsoft#9106) Adds scenario tests for array encoding on model properties, covering all four `ArrayEncoding` variants. ## Changes - **New test folder**: `packages/http-specs/specs/encode/array/` - **Scenarios added**: - `commaDelimited` (CSV) - values joined with `,` - `spaceDelimited` (SSV) - values joined with ` ` - `pipeDelimited` - values joined with `|` - `newlineDelimited` - values joined with `\n` ## Example ```tsp model CommaDelimitedArrayProperty { @encode(ArrayEncoding.commaDelimited) value: string[]; } @route("/property/comma-delimited") @post op commaDelimited(@Body body: CommaDelimitedArrayProperty): CommaDelimitedArrayProperty; ``` Expected request/response body: ```json { "value": "blue,red,green" } ``` > [!WARNING] > > <details> > <summary>Firewall rules blocked me from connecting to one or more addresses (expand for details)</summary> > > #### I tried to connect to the following addresses, but was blocked by firewall rules: > > - `telemetry.astro.build` > - Triggering command: `/usr/local/bin/node node /home/REDACTED/work/typespec/typespec/website/node_modules/.bin/../astro/astro.js build` (dns block) > > If you need me to access, download, or install something from one of these locations, you can either: > > - Configure [Actions setup steps](https://gh.io/copilot/actions-setup-steps) to set up my environment, which run before the firewall is enabled > - Add the appropriate URLs or hosts to the custom allowlist in this repository's [Copilot coding agent settings](https://github.com/microsoft/typespec/settings/copilot/coding_agent) (admins only) > > </details> <!-- START COPILOT CODING AGENT SUFFIX --> <details> <summary>Original prompt</summary> > > ---- > > *This section details on the original issue you should resolve* > > <issue_title>CSV encoding for model properties Scenario tests</issue_title> > <issue_description>Add http-specs tests for array encoding, including all four encode. Add a new folder under packages/http-specs/specs/encode.</issue_description> > > ## Comments on the Issue (you are @copilot in this section) > > <comments> > </comments> > </details> - Fixes microsoft#9029 <!-- START COPILOT CODING AGENT TIPS --> --- 💬 We'd love your input! Share your thoughts on Copilot coding agent in our [2 minute survey](https://gh.io/copilot-coding-agent-survey). --------- Co-authored-by: copilot-swe-agent[bot] <[email protected]> Co-authored-by: tadelesh <[email protected]> Co-authored-by: tadelesh <[email protected]>
…ft#9140) Bumps [jws](https://github.com/brianloveswords/node-jws) from 3.2.2 to 3.2.3. <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/brianloveswords/node-jws/releases">jws's releases</a>.</em></p> <blockquote> <h2>v3.2.3</h2> <h3>Changed</h3> <ul> <li>Fix advisory GHSA-869p-cjfg-cm3x: createSign and createVerify now require that a non empty secret is provided (via opts.secret, opts.privateKey or opts.key) when using HMAC algorithms.</li> <li>Upgrading JWA version to 1.4.2, addressing a compatibility issue for Node >= 25.</li> </ul> </blockquote> </details> <details> <summary>Changelog</summary> <p><em>Sourced from <a href="https://github.com/auth0/node-jws/blob/master/CHANGELOG.md">jws's changelog</a>.</em></p> <blockquote> <h2>[3.2.3]</h2> <h3>Changed</h3> <ul> <li>Fix advisory GHSA-869p-cjfg-cm3x: createSign and createVerify now require that a non empty secret is provided (via opts.secret, opts.privateKey or opts.key) when using HMAC algorithms.</li> <li>Upgrading JWA version to 1.4.2, adressing a compatibility issue for Node >= 25.</li> </ul> <h2>[3.0.0]</h2> <h3>Changed</h3> <ul> <li><strong>BREAKING</strong>: <code>jwt.verify</code> now requires an <code>algorithm</code> parameter, and <code>jws.createVerify</code> requires an <code>algorithm</code> option. The <code>"alg"</code> field signature headers is ignored. This mitigates a critical security flaw in the library which would allow an attacker to generate signatures with arbitrary contents that would be accepted by <code>jwt.verify</code>. See <a href="https://auth0.com/blog/2015/03/31/critical-vulnerabilities-in-json-web-token-libraries/">https://auth0.com/blog/2015/03/31/critical-vulnerabilities-in-json-web-token-libraries/</a> for details.</li> </ul> <h2><a href="https://github.com/brianloveswords/node-jws/compare/v1.0.1...v2.0.0">2.0.0</a> - 2015-01-30</h2> <h3>Changed</h3> <ul> <li> <p><strong>BREAKING</strong>: Default payload encoding changed from <code>binary</code> to <code>utf8</code>. <code>utf8</code> is a is a more sensible default than <code>binary</code> because many payloads, as far as I can tell, will contain user-facing strings that could be in any language. (<!-- raw HTML omitted --><a href="https://github.com/brianloveswords/node-jws/commit/6b6de48">6b6de48</a><!-- raw HTML omitted -->)</p> </li> <li> <p>Code reorganization, thanks <a href="https://github.com/fearphage"><code>@fearphage</code></a>! (<!-- raw HTML omitted --><a href="https://github.com/brianloveswords/node-jws/commit/7880050">7880050</a><!-- raw HTML omitted -->)</p> </li> </ul> <h3>Added</h3> <ul> <li>Option in all relevant methods for <code>encoding</code>. For those few users that might be depending on a <code>binary</code> encoding of the messages, this is for them. (<!-- raw HTML omitted --><a href="https://github.com/brianloveswords/node-jws/commit/6b6de48">6b6de48</a><!-- raw HTML omitted -->)</li> </ul> </blockquote> </details> <details> <summary>Commits</summary> <ul> <li><a href="https://github.com/auth0/node-jws/commit/4f6e73f24df42f07d632dec6431ade8eda8d11a6"><code>4f6e73f</code></a> Merge commit from fork</li> <li><a href="https://github.com/auth0/node-jws/commit/bd0fea57f35a97b6749a632b19ae5100d6d35729"><code>bd0fea5</code></a> version 3.2.3</li> <li><a href="https://github.com/auth0/node-jws/commit/7c3b4b411004c206af8901fa3f8e644127bbf8d9"><code>7c3b4b4</code></a> Enhance tests for HMAC streaming sign and verify</li> <li><a href="https://github.com/auth0/node-jws/commit/a9b8ed999de8f8fff486ac9167514577a0fae323"><code>a9b8ed9</code></a> Improve secretOrKey initialization in VerifyStream</li> <li><a href="https://github.com/auth0/node-jws/commit/6707fde62cbae465a7f11e52760fb994dbc0e0dc"><code>6707fde</code></a> Improve secret handling in SignStream</li> <li>See full diff in <a href="https://github.com/brianloveswords/node-jws/compare/v3.2.2...v3.2.3">compare view</a></li> </ul> </details> <details> <summary>Maintainer changes</summary> <p>This version was pushed to npm by <a href="https://www.npmjs.com/~julien.wollscheid">julien.wollscheid</a>, a new releaser for jws since your current version.</p> </details> <br /> [](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- <details> <summary>Dependabot commands and options</summary> <br /> You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot show <dependency name> ignore conditions` will show all of the ignore conditions of the specified dependency - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) You can disable automated security fix PRs for this repo from the [Security Alerts page](https://github.com/microsoft/typespec/network/alerts). </details> Signed-off-by: dependabot[bot] <[email protected]> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
- Add rename-types.transform.ts for GraphQL name sanitization - Add sanitizeNameForGraphQL utility function - Add transformer.ts to define graphql transformer library - Add comprehensive tests for rename-types transform - Update package.json with mutator-framework dependency
Adds validation test for `module-info.java` formatting and cleans up partial update tests.
…emplates (microsoft#8917) Add warning to documentation and CLI help for templateUrl parameter in tsp init command **Completed:** - [x] Explore repository structure and locate documentation files - [x] Install dependencies - [x] Add warning to CLI reference documentation (/website/src/content/docs/docs/handbook/cli.md) - [x] Add warning to scaffolding template documentation (/website/src/content/docs/docs/extending-typespec/writing-scaffolding-template.md) - [x] Add warning to templatesUrl parameter description in CLI code (packages/compiler/src/core/cli/cli.ts) - [x] Build and validate the documentation changes - [x] Address code review feedback for consistency - [x] Add changelog entry for @typespec/compiler referencing issue microsoft#8916 - [x] Review and finalize **Changes Made:** - Added security warnings to both the CLI handbook and scaffolding templates documentation - Added security warning to the templatesUrl parameter description in the CLI code, which appears in the `tsp init --help` output - The warnings inform users that downloading or using an untrusted template may contain malicious packages that can compromise their system and data, matching the warning prompt shown in the `tsp init` command - Warning text is consistent across documentation files and CLI help - Added changelog entry using chronus format for @typespec/compiler package only (no changelog needed for website documentation changes) - Fixes microsoft#8916 <!-- START COPILOT CODING AGENT SUFFIX --> <details> <summary>Original prompt</summary> > > ---- > > *This section details on the original issue you should resolve* > > <issue_title>Add warning text to documentation on `templateUrl` parameter in tsp init command</issue_title> > <issue_description>External templates *can* contain malicious packages and the like. We prompt about this when folks use `tsp init`: > > ```bash > warning: Downloading or using an untrusted template may contain malicious packages that can compromise your system and data. Proceed with caution and verify the source. > ? Continue (Y/n) > ``` > > We should also add a similar warning to the reference doc on tsp init</issue_description> > > <agent_instructions>Add a warning to the documentation on the templateUrl parameter to `tsp init`, similar to the warning prompt mentioned in the bug. It should be clear to users that using tsp init with an external templateUrl is unsafe, unless the template source is trusted.</agent_instructions> > > ## Comments on the Issue (you are @copilot in this section) > > <comments> > </comments> > </details> - Fixes microsoft#8916 <!-- START COPILOT CODING AGENT TIPS --> --- ✨ Let Copilot coding agent [set things up for you](https://github.com/microsoft/typespec/issues/new?title=✨+Set+up+Copilot+instructions&body=Configure%20instructions%20for%20this%20repository%20as%20documented%20in%20%5BBest%20practices%20for%20Copilot%20coding%20agent%20in%20your%20repository%5D%28https://gh.io/copilot-coding-agent-tips%29%2E%0A%0A%3COnboard%20this%20repo%3E&assignees=copilot) — coding agent works faster and does higher quality work when set up for your repo. --------- Co-authored-by: copilot-swe-agent[bot] <[email protected]> Co-authored-by: markcowl <[email protected]>
This pull request refines the logic for handling multi-level discriminators in model constructor initialization within `ModelProvider.cs`. The changes ensure more accurate passing of discriminator parameters in complex inheritance scenarios, improving both correctness and maintainability. ### Multi-level discriminator handling improvements * Updated the logic to check whether the current model or base model uses a multi-level discriminator, ensuring the correct constructor is called and the appropriate discriminator value is passed in multi-level inheritance scenarios. * Enhanced the handling of discriminator parameters: now, when initializing constructors, the code attempts to pass through the discriminator parameter from the base model if available, otherwise falls back to using the current model's discriminator value. * Improved the logic in `GetExpressionForCtor` to correctly decide when to pass through the discriminator parameter or use the model's own discriminator value, based on whether the model is part of a multi-level discriminator hierarchy. ### Constructor initialization logic * Ensured that base constructor calls are properly made even when there are no base parameters, maintaining correct inheritance behavior.
fix microsoft#9137 Related PR: - [ ] microsoft#9139
…t#9145) Caused by microsoft#9109 Happens in mgmt flow, where we clean up unused model. Therefore, when we use FinalResult (instead of Response) model from LRO, we'd need to change this logic too. --- test Azure/autorest.java#3237 Azure/azure-sdk-for-java#47475 (some model get removed, Build pass)
decorator (microsoft#9151) - [x] Analyze the issue: OpenAPI 3.1/3.2 schemas with `contentEncoding: base64` should be imported as `bytes` type with `@encode("base64", string)` decorator - [x] Understand the codebase: The import/convert functionality is in `packages/openapi3/src/cli/actions/convert/` - [x] Modify `generate-types.ts` (`getStringType` function) to handle `contentEncoding: base64` and return `bytes` type - [x] Modify `decorators.ts` (`getStringSchemaDecorators` function) to add `@encode("base64", string)` decorator when `contentEncoding: base64` - [x] Add tests to verify the fix - [x] Run format and lint commands - [x] Add changelog entry - [x] Run code review and address feedback - [x] Manually verify the generated TypeSpec output is correct - [x] Fix TypeScript build error in data-types.test.ts ## Summary This PR fixes the import of OpenAPI 3.1/3.2 schemas with `contentEncoding: base64`. **Before this fix:** ```yaml # OpenAPI 3.1/3.2 properties: b64_json: type: string contentEncoding: base64 ``` Was incorrectly imported as: ```typespec model Foo { b64_json?: string; // Wrong! } ``` **After this fix:** ```typespec model Foo { @encode("base64", string) b64_json?: bytes; // Correct! } ``` ## Security Summary The changes are minimal and focused on type detection during import. No security vulnerabilities were introduced. <!-- START COPILOT ORIGINAL PROMPT --> <details> <summary>Original prompt</summary> > > ---- > > *This section details on the original issue you should resolve* > > <issue_title>import - base64 content encoding should be imported as bytes</issue_title> > <issue_description>### Clear and concise description of the problem > > The following TypeSpec definition > > ```typespec > model Foo { > @encode("base64", string) > b64_json?: bytes; > } > ``` > > Leads to the follow OpenAPI 3.1/3.2 descriptions > > ```yaml > openapi: 3.2.0 > info: > title: (title) > version: 0.0.0 > tags: [] > paths: {} > components: > schemas: > Foo: > type: object > properties: > b64_json: > type: string > contentEncoding: base64 > ``` > > And the following OpenAPI 3.0 description > > ```yaml > openapi: 3.0.0 > info: > title: (title) > version: 0.0.0 > tags: [] > paths: {} > components: > schemas: > Foo: > type: object > properties: > b64_json: > type: string > format: base64 > ``` > > > But importing those to TypeSpec leads to the following result in 3.1/3.2 > > ```typespec > model Foo { > b64_json?: string; > } > ``` > > And this result in 3.0 > > ```typespec > model Foo { > @Format("base64") b64_json?: string; > } > ``` > > The import result looks correct for OpenAPI 3.0 due to the lack of support for contentEncoding. However the import in 3.1/3.2 should lead to a bytes type and an encode decorator. > > > ### Checklist > > - [x] Follow our [Code of Conduct](https://github.com/microsoft/typespec/blob/main/CODE_OF_CONDUCT.md) > - [x] Read the [docs](https://typespec.io/docs/). > - [x] Check that there isn't already an issue that request the same feature to avoid creating a duplicate.</issue_description> > > <agent_instructions>make sure you run the format and lint commands before each commit. > use conventional commits. > run `npx @chronus/chronus add` to add a bugfix changelog entry when done with the changes.</agent_instructions> > > ## Comments on the Issue (you are @copilot in this section) > > <comments> > </comments> > </details> <!-- START COPILOT CODING AGENT SUFFIX --> - Fixes microsoft#9150 <!-- START COPILOT CODING AGENT TIPS --> --- ✨ Let Copilot coding agent [set things up for you](https://github.com/microsoft/typespec/issues/new?title=✨+Set+up+Copilot+instructions&body=Configure%20instructions%20for%20this%20repository%20as%20documented%20in%20%5BBest%20practices%20for%20Copilot%20coding%20agent%20in%20your%20repository%5D%28https://gh.io/copilot-coding-agent-tips%29%2E%0A%0A%3COnboard%20this%20repo%3E&assignees=copilot) — coding agent works faster and does higher quality work when set up for your repo. --------- Co-authored-by: copilot-swe-agent[bot] <[email protected]> Co-authored-by: baywet <[email protected]> Co-authored-by: Vincent Biret <[email protected]> Co-authored-by: Timothee Guerin <[email protected]>
…ion (microsoft#9153) - [x] Add `InputExternalTypeMetadata` interface to TypeScript for external type metadata - [x] Add `external` property to TypeScript `InputTypeBase` interface - [x] Create `fromSdkExternalTypeInfo` helper function to convert TCGC external info - [x] Update `fromSdkType` to use helper function instead of extracting inline - [x] Remove separate `InputExternalType` handling and preserve original type structure - [x] Create C# `InputExternalTypeMetadata` class - [x] Add `External` property to C# `InputType` class - [x] Create `InputExternalTypeMetadataConverter` for JSON serialization - [x] Update all type converters to handle External property - [x] Delete `InputExternalType` class and converter - [x] Update `TypeFactory.CreateCSharpTypeCore` to check External property first - [x] Update `CreateExternalType` to accept `InputExternalTypeMetadata` - [x] Update tests to validate external property is set on original types - [x] Add optional `InputExternalTypeMetadata` parameter to all applicable InputFactory methods (Union, Array, Dictionary, Model, Enum) - [x] Add comprehensive tests for External property deserialization (Union, Model, Array, Dictionary, Enum) - [x] Run all tests to ensure no regressions <!-- START COPILOT ORIGINAL PROMPT --> <details> <summary>Original prompt</summary> > > ---- > > *This section details on the original issue you should resolve* > > <issue_title>Include original input type information for external types</issue_title> > <issue_description>For the case of DFE in particular, we expect tsp like the following: > ``` > @doc("Expression model for DataFactory expressions") > model DfeExpressionModel { > @doc("The type of expression") > type: "Expression"; > @doc("The expression value") > value: string; > } > > // DataFactoryElement alternate type pattern > @alternateType({identity: "Azure.Core.Expressions.DataFactoryElement"}, "csharp") > union Dfe<T> { > T, > DfeExpressionModel > } > > @doc("Model with DataFactoryElement properties") > model DataFactoryElementModel { > @doc("String property with DFE pattern") > stringProperty: Dfe<string>; > > @doc("Int property with DFE pattern") > intProperty: Dfe<int32>; > > @doc("Bool property with DFE pattern") > boolProperty: Dfe<boolean>; > > @doc("String array property with DFE pattern") > stringArrayProperty: Dfe<string[]>; > } > ``` > > Right now, the union is replaced in the C# emitter with an external type. We should include a property on the external type that contains the original input type that was replaced. This is needed for DFE as we need to be able to get the union variant that represents the generic argument. There may be similar scenarios for other alternate types so we should just include the original input type as a property on the constructed external type in the emitter. We will need to update the C# InputExternalType to have a corresponding `Original` property of type `InputType`.</issue_description> > > ## Comments on the Issue (you are @copilot in this section) > > <comments> > </comments> > </details> <!-- START COPILOT CODING AGENT SUFFIX --> - Fixes microsoft#9152 <!-- START COPILOT CODING AGENT TIPS --> --- 💬 We'd love your input! Share your thoughts on Copilot coding agent in our [2 minute survey](https://gh.io/copilot-coding-agent-survey). --------- Co-authored-by: copilot-swe-agent[bot] <[email protected]> Co-authored-by: JoshLove-msft <[email protected]> Co-authored-by: jolov <[email protected]>
…ormat (microsoft#9164) When importing OpenAPI schemas with `anyOf`/`oneOf` containing `{type: "integer", format: "unixtime"}` and `{type: "null"}`, the converter was dropping the `@encode(DateTimeKnownEncoding.unixTimestamp, integer)` decorator. **Before:** ```yaml finished_at: anyOf: - type: integer format: unixtime - type: "null" ``` ```typespec finished_at?: utcDateTime | null // Missing @encode decorator ``` **After:** ```typespec @encode(DateTimeKnownEncoding.unixTimestamp, integer) finished_at?: utcDateTime | null ``` ## Changes - **`decorators.ts`**: Modified `getDecoratorsForSchema` to extract `format` property from `anyOf`/`oneOf` members when not present at schema root - **Tests**: Added coverage for both `anyOf` and `oneOf` union variants with unixtime format - **Changelog**: Added fix entry for @typespec/openapi3 <!-- START COPILOT ORIGINAL PROMPT --> <details> <summary>Original prompt</summary> > > ---- > > *This section details on the original issue you should resolve* > > <issue_title>converter - import anyOf unixtime missed decorator</issue_title> > <issue_description>When importing this OpenAPI schema > > ```yaml > components: > schemas: > FineTuningJob: > type: object > properties: > created_at: > type: integer > description: The Unix timestamp (in seconds) for when the fine-tuning job was created. > format: unixtime > ``` > > I get the following result > > ```typespec > @encode(DateTimeKnownEncoding.unixTimestamp, integer) created_at: utcDateTime > ``` > > However, if the schema is instead an anyOf with null, I get the following TypeSpec result, which misses the encode decorator > > ```yaml > components: > schemas: > FineTuningJob: > type: object > properties: > finished_at: > anyOf: > - type: integer > description: The Unix timestamp (in seconds) for when the fine-tuning job was finished. The value will be null if the fine-tuning job is still running. > format: unixtime > - type: "null" > ``` > > ```typespec > finished_at: utcDateTime | null > ``` > > The decorator should be present whenever a union type with null is emitted.</issue_description> > > <agent_instructions>run the formatting script before any commit. > when you're done with all the changes, run `npx @chronus/chronus add` to add a bugfix entry to the changelog. > use conventional commits.</agent_instructions> > > ## Comments on the Issue (you are @copilot in this section) > > <comments> > </comments> > </details> <!-- START COPILOT CODING AGENT SUFFIX --> - Fixes microsoft#9163 <!-- START COPILOT CODING AGENT TIPS --> --- 💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more [Copilot coding agent tips](https://gh.io/copilot-coding-agent-tips) in the docs. --------- Co-authored-by: copilot-swe-agent[bot] <[email protected]> Co-authored-by: baywet <[email protected]> Co-authored-by: Vincent Biret <[email protected]> Co-authored-by: Timothee Guerin <[email protected]>
For framework types that are generic where the arg may be a non-framework type, we lose the generic type arg information when using Type.
Follow up to : microsoft#9166. This exposes the internal CSharpType comparer, to be consumed by the azure generator in it's serialization hooks.
…soft#9177) Co-authored-by: Jorge Rangel <[email protected]>
These use a different codepath in HSJS than JSON properties, and that codepath was mishandling optional parameters by unconditionally passing them into `globalThis.Number`/`globalThis.Boolean`, etc. This patch adds an explicit check for `undefined` and transposes that to `undefined` instead of calling the parser unconditionally, which will return the default value. For parsers that don't accept `undefined` as an input, this would have triggered a type error or runtime error. Closes microsoft#9156
…rosoft#9181) The generator prevented customizing a model's base type when the TypeSpec already specified a base model. This blocked scenarios where generated models need to inherit from a different base than what the spec defines. ## Changes - **Modified `ModelProvider.BuildBaseModelProvider()`**: Check for `CustomCodeView?.BaseType` before falling back to `_inputModel.BaseModel`, enabling custom base types to override spec-defined base models - **Added test `CanCustomizeBaseModelWithSpecBase`**: Verifies that a model with a spec-defined base can be customized to inherit from a different base model instead ## Example Given a TypeSpec model with a base: ```csharp // Spec defines: MockInputModel extends SpecBaseModel ``` Users can now customize it to use a different base: ```csharp namespace Sample.Models { public partial class MockInputModel : CustomBaseModel // Overrides spec base { } } ``` The generated code will respect the custom base type instead of the spec-defined one. <!-- START COPILOT ORIGINAL PROMPT --> <details> <summary>Original prompt</summary> > > ---- > > *This section details on the original issue you should resolve* > > <issue_title>Unable to customize base model of generated model if spec has a base model</issue_title> > <issue_description>In MTG, we can only customize base model if input model doesn't have a base model already. > https://github.com/microsoft/typespec/blob/fecf4f2300b88dc663f27dcb3f37bff78313a17b/packages/http-client-csharp/generator/Microsoft.TypeSpec.Generator/src/Providers/ModelProvider.cs#L245-L250 > > There are cases, we need to customize the base model even the spec has specified the base model.</issue_description> > > <agent_instructions>remove the input model base model check and add a unit test to verify the scenario</agent_instructions> > > ## Comments on the Issue (you are @copilot in this section) > > <comments> > </comments> > </details> <!-- START COPILOT CODING AGENT SUFFIX --> - Fixes microsoft#9180 <!-- START COPILOT CODING AGENT TIPS --> --- 💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more [Copilot coding agent tips](https://gh.io/copilot-coding-agent-tips) in the docs. --------- Co-authored-by: copilot-swe-agent[bot] <[email protected]> Co-authored-by: live1206 <[email protected]>
add case to cover microsoft#8787
Fix https://teams.microsoft.com/l/message/19:[email protected]/1762191788524?tenantId=72f988bf-86f1-41af-91ab-2d7cd011db47&groupId=3e17dcb0-4257-4a30-b843-77f47f1d4121&parentMessageId=1762191788524&teamName=Azure%20SDK&channelName=Language%20-%20Python&createdTime=1762191788524 - The indent logic is more and more complicated so we must add test case to cover related scenarios. Then I introduce local specs to cover the target docstring scenarios in this PR. - local test specs: https://github.com/Azure/autorest.python/pull/3258/files#diff-11c3177c467ef6e1428ddb7c9180ad769cf3d5596f95b4ae33c6bfb6e32b8898 and here is generated sdk docstring: https://github.com/Azure/autorest.python/pull/3258/files#diff-4ca5eea376710573c60f99fba775abf18df7302a8871df4cd74aed290e97175b **NOTE**: If Typespec author add `\n` by themselves in original docstring (e.g. [here](https://github.com/Azure/azure-rest-api-specs-pr/blob/4a11877293189d99a93774a58d2e340fc8cdf6d2/specification/ai/Azure.AI.Projects/.external-readonly/azure.openai.v1.typespec/models/responses.tsp#L17-L27)), this PR still can't resolve indent issue. But just need to give up the line break like this [commit](Azure/azure-rest-api-specs-pr@6cecfc0), the issue of Python SDK docstring could be avoided. pending on: - [x] microsoft#8929
…n http-client-csharp (microsoft#9179) ## Upgrade TypeSpec compiler and related libraries to latest versions - [x] Update `@typespec/http-client-csharp` package.json dependencies - [x] Upgrade `@typespec/compiler` from ^1.6.0 to ^1.7.0 (peerDependencies and devDependencies) - [x] Upgrade `@typespec/http` from ^1.6.0 to ^1.7.0 (peerDependencies and devDependencies) - [x] Upgrade `@typespec/openapi` from ^1.6.0 to ^1.7.0 (peerDependencies and devDependencies) - [x] Upgrade `@typespec/json-schema` from 1.6.0 to 1.7.0 (devDependencies) - [x] Upgrade `@typespec/rest` from 0.76.0 to 0.77.0 (peerDependencies and devDependencies) - [x] Upgrade `@typespec/streams` from 0.76.0 to 0.77.0 (peerDependencies and devDependencies) - [x] Upgrade `@typespec/versioning` from 0.76.0 to 0.77.0 (peerDependencies and devDependencies) - [x] Upgrade `@typespec/xml` from 0.76.0 to 0.77.0 (devDependencies) - [x] Upgrade `@typespec/library-linter` from 0.76.0 to 0.77.0 (devDependencies) - [x] Upgrade `@azure-tools/typespec-client-generator-core` from 0.62.0 to 0.63.0 (devDependencies) - [x] Upgrade `@azure-tools/typespec-client-generator-core` peerDependency from `>=0.62.0 < 0.63.0 || ~0.63.0-0` to `>=0.63.0 < 0.64.0 || ~0.64.0-0` (following existing pattern) - [x] Upgrade `@azure-tools/azure-http-specs` from 0.1.0-alpha.32 to 0.1.0-alpha.33 (devDependencies) - [x] Run `npm install --legacy-peer-deps` in http-client-csharp to update package-lock.json - [x] Verify http-specs uses workspace dependencies (confirmed: uses `workspace:^` for all TypeSpec packages, automatically resolves to latest versions) - [x] Verify no breaking changes in upgraded versions (confirmed: all updates are non-breaking, mostly dependency bumps and minor features) ### Summary Successfully upgraded http-client-csharp to use the latest TypeSpec compiler (1.7.0) and related libraries (0.77.0 for rest/versioning/streams/xml), and upgraded @Azure-Tools packages to their latest versions (client-generator-core 0.63.0 and azure-http-specs 0.1.0-alpha.33). All version ranges follow the existing pattern used in the package. All version upgrades are non-breaking changes. <!-- START COPILOT ORIGINAL PROMPT --> <details> <summary>Original prompt</summary> > > ---- > > *This section details on the original issue you should resolve* > > <issue_title>Upgrade to latest compiler version</issue_title> > <issue_description>typesspec/compiler and all related libraries.</issue_description> > > ## Comments on the Issue (you are @copilot in this section) > > <comments> > </comments> > </details> <!-- START COPILOT CODING AGENT SUFFIX --> - Fixes microsoft#9178 <!-- START COPILOT CODING AGENT TIPS --> --- ✨ Let Copilot coding agent [set things up for you](https://github.com/microsoft/typespec/issues/new?title=✨+Set+up+Copilot+instructions&body=Configure%20instructions%20for%20this%20repository%20as%20documented%20in%20%5BBest%20practices%20for%20Copilot%20coding%20agent%20in%20your%20repository%5D%28https://gh.io/copilot-coding-agent-tips%29%2E%0A%0A%3COnboard%20this%20repo%3E&assignees=copilot) — coding agent works faster and does higher quality work when set up for your repo. --------- Co-authored-by: copilot-swe-agent[bot] <[email protected]> Co-authored-by: JoshLove-msft <[email protected]> Co-authored-by: jolov <[email protected]>
Fix microsoft#9185 Also tried with copilot, but not all dependencies are bumped, try to at copilot but still not correctly updated : microsoft#9186 ends up to first create a manual PR, and later tune instructions. I'm referring this PR: microsoft#8993 No breaking changes so bump a patch version
…rialization (microsoft#9146) fix microsoft#9026 TCGC is ready: Azure/typespec-azure#3583 Spector case: microsoft#9106
fix microsoft#8560(keyboard not working) fix microsoft#8559(role)
This PR refactors the enum creation to allow visitors to mutate an enum's namespace and the generator to load any custom code in the new namespace for said visitor, before the final enum type is added to the output library. fixes: Azure/azure-sdk-for-net#54368
Mostly whitespace changes on account of random empty things not making newlines anymore.
fix microsoft#8556 (Search pane outline) fix microsoft#8722 (Links not underlined) fix microsoft#8557 (Learn more links) fix microsoft#8598 (Terminal/ide image issue) fix microsoft#8597 (Hide menu items in docs) fix microsoft#8556 (Keyboard focus order in hamburget menu) <img width="957" height="926" alt="image" src="https://github.com/user-attachments/assets/65d4bd79-b57b-4608-8fea-b615bbb615fc" /> --------- Co-authored-by: Mark Cowlishaw <[email protected]>
Having used these tools for a reasonably complete REST emitter, the following fixes and improvements have been implemented: ## Mutator framework ### General * Fix mutations not handling linkage to parent types (e.g. model property -> model). * Remove mutation subgraph, nodes are now unique per (type, key) pair. * Remove reference mutations, use a distinct key for references if needed. * Added various `SimpleMutation`s and `SimpleMutationEngine` for doing mutations of the graph where only one mutated type is needed per source type. ### Mutation Nodes * Connections are now built lazily. Nodes get a `startXEdge` method which returns a `HalfEdge` that can be connected to the mutation node for that type. This is necessary because we can't know what node we're going to connect to in advance (since it depends on the eventual `mutationKey` we'll calculate for it, see below). The only exception to this is when connecting to member types which refer back to the member container - connecting the container to a member will connect the member to the container. ### Mutations * Mutations are now abstract classes. * Mutations have a new protocol - a static method `mutationInfo` is called which returns a unique `mutationKey` for that mutation (along with other information if needed). If the `mutationKey` has been seen before, the previous one is returned. Otherwise, the appropriate `Mutation` is constructed passing along the mutationInfo. * `mutationInfo` can also return a `Mutation`, in which case it is used directly. Useful for constructing a Mutation view "as if" the type graph looked a different way. * Mutations have methods to create `MutationHalfEdge` types for connected type which can be passed along to the engine's `mutate` method. When we figure out what `Mutation` to use based on the `mutationKey` we calculate, it is connected by calling `setTail`. ## HTTP Canonicalization ### General * Fix canonicalization of merge patch models. * Remove metadata properties from wire types. * Added a new method `subgraphMatchesPredicate` to `HttpCanonicalizer` and `HttpCanonicalization` classes. This is a cycle safe way to see if the subgraph rooted at a particular canonicalization all have a certain property. * Various fixes and improvements to union variant discrimination tests * Normalize @Discriminator models on base type to a union of their subtypes when appropriate. * Add support for "extensible union" pattern * Add support for requests/responses multiple content types * Apply getEffectiveModel to all models. ### Codecs * Codecs have a new protocol - the `detect` method has been removed, codec instances have `encode` which either returns `null` or `EncodingInfo` if it encodes the given type. * Codecs now operate on types rather than http canonicalizations (making them more general purpose) * Codecs can be configured by constructing them with various options. CoerceToFloat64 codec has options for whether to encode int64,decimal, etc. * Added a Rename codec to rename the language type for types which have friendlyName, or have language-specific case conventions that differ from the API. ## Emitter framework * Add an SCCSet class which incrementally calculates strongly connected components from types added to it and updates reactive arrays with the topologically ordered types and components.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This change demonstrates how we can use the new Mutation Framework's mutation engine as our encapsulator of mutations which can then be reused across emitter libraries.