-
Notifications
You must be signed in to change notification settings - Fork 739
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
How to express an "any" type for a property. #2855
Comments
@amarzavery I dug into the code for I'd have to implement a custom serializer and then doctor the generated autorest code after each run which also sucks... |
@Stevenic you're on to likely AutoRest's biggest weirdness! #2827 Indeed, we unfortunately had the wrong behavior in the past, and as detailed in said issue, it's not too trivial to fix: As always, if you have weird behavior, people (including us) start depending on it. Not sure what the timeline is to fix up our own Swaggers (to not rely on wrong behavior anymore), but right after that is done, we'll fix up code generation. Until then, maybe @amarzavery has some way to unblock you (autorest can actually include minor string-smashing-style doctoring into it's codegeneration, maybe we can brew something together) |
I had read that issue so I had already assumed this was likely a core issues but was hopeful I could easily work around it without needing to do anything crazy. It doesn't look like it from my 30 minute dig through your code. The issue we have is we have a |
Thanks for your digging efforts, I'm unfortunately in the dark about NodeJS code gen but what you say makes sense - I think I remember similar cases, the mapper is quite rigid. I'll check what @amarzavery's plans regarding |
@Stevenic The legendary @amarzavery has spoken: He'll update value: {
required: false,
serializedName: 'value',
type: {
name: 'Any' // <======= new thing here
}
} Long term, this will be what AutoRest generates for your Swagger, but well, you know about the issue tracking that 😉 Until then, I'll happily assist you to hack something into your generation command that'll replace |
@Stevenic - 0.2.6 version of ms-rest-js with support for [de]serializing "any" type has been published. |
Awesome! Thanks @olydis. We already have a post processing script to do other similar fixups so I should be good. Thanks again for the quick turn around :) |
@Stevenic - What are the other fixups that you have to do on the generated client? I am curious to know. It would be nice to get you to a position where no post generation scripts would be required. |
@amarzavery String enums don't behave the same way in TypeScript as they do in .NET. TypeScript will generate a String enum well enough but then it forces the developer to always use the enum. So lets say you end up generating this: export enum PetTypes {
Cat = "cat",
Dog = "dog",
Fish = "fish"
}
export interface Pet {
type: PetTypes;
name: string;
age: number;
} If a developer tries to do this: const pet: Pet = {
type: 'cat',
name: 'fluffy',
age: 7
}; They will get a compiler error. TypeScript forces you to do: const pet: Pet = {
type: PetTypes.Cat,
name: 'fluffy',
age: 7
}; While its fine that you can use the enum it sucks as a JavaScript/TypeScript developer to have to use the enum. So we patch every property that takes a string enum to use a union type: export interface Pet {
type: PetTypes|string;
name: string;
age: number;
} Apparently C# will accept either without the patch so just another language inconsistency. It's also worth noting that the We have some other patches around converting things to take |
I'm trying to work out how to express a property that's an "any" type using swagger and autorest. What I found through searching the web is that in swagger 2.0 you need to simply remove the "type" for a property to say its an any which if you look at my value property you'll see I've done:
But when I run this through autorest using the
--typescript
switch get a mapping to typeobject
in the generatedmapper.ts
file which causes the generated client to fail the outbound serialization for non-object values:Is this just a bug in the typescript plugin?
The text was updated successfully, but these errors were encountered: