I'm dealing with a funky authentication process that requires me to:

1. Hit an endpoint with redirects set to 0 or handle all responses in the chain
2. Take the Set-Cookie header value from the first response and supply it with all future requests in the Cookie header

I'm attempting to accomplish this through a custom implementation of ServiceClientCredentials utilizing Axios(for now at least). For the life of me, whatever I try, the cookie header ends up blank on the wire. It appears some effort was made to get cookies working with fetch, however I can't get them working for myself :)

Any guidance on this would be much appreciated(or if I could convince you to utilize Axios :D ).

I'm using AutoRest to generate a typescript rest client and converting that to ES6 to be used in a React Native app. The generated client relies on the 'ms-rest-js' runtime which relies on the nodejs module 'os' to hydrate the operating system info on the user agent string in the MsRestUserAgentFilter. Unfortunately the 'os' module is not implemented in React Native as far as I'm aware.

I can pull in the nodejs 'os' module to get the bundler to succeed but unfortunately 'detect-node' returns true when running within React Native. This causes code to execute against the 'os' module but it's not implemented within React Native which yields a runtime error at line 23 of msRestUserAgentFilter.ts:
const osInfo = '(${os.arch()}-${os.type()}-${os.release()})';

If I use a debugger and set IsNode to false, everything works as expected.

When I manually replace the module dependency 'os' with 'react-native-os' in this scenario, everything behaves as expected. I spent a few hours attempting to alias require('os') to require('react-native-os') in my build but couldn't get it working. It's also hacky.

React Native may fall outside of intended use cases, but I'd be much obliged if 'ms-rest-js' (or an alternative package) could work in React Native without modification on my end, either by relying on the appropriate dependency ('react-native-os' vs 'os'), or by optionally bypassing/overriding the operating system info on the user agent string.

I'm finding places like interface RequestPrepareOptions where we are documenting the interface members as if they are method parameters. This prevents the jsdoc from showing in the IDE.

In general the members should show the documentation on hover in vscode--if they don't, that's how you know something is wrong.

Let's remove all *.js, *.js.map, and *.d.ts files from version control, as we did in autorest.typescript. This will make our diffs cleaner and make it easier to keep the repo in a consistent state. Conversely, let's use .npmignore to ensure that we don't publish any of our source *.js or *.js.map files in the npm package.

This task also applies to Azure/ms-rest-azure-js.

@amarzavery @daschult I'm thinking that we should have a better place to publish our bundle files than the master branch of the repo. Any site which simply loads a bundle built from the tip of master every time their page loads is bound to break down the line.

How about we use GitHub Releases to make each version of the bundle available via HTTPS? Then users will specify in the URL which version of the library they're trying to load.

In order to support older Browsers like IE11 or Firefox 45 the source code needs to be compiled against ES5. (Currently ES6)

In the latest implementation of TypeSpecs, we search the CompositeTypeSpec hierarchy for every operation when we need to match a provided value against the CompositeTypeSpec hierarchy. @amarzavery pointed out that we could push much of this computation to the generator.

Looking into some problems I'm having. Any request I make with autorest.typescript always returns undefined.

The reason I think* is that my server sets the content type to this:

Content-Type: application/json; charset=utf-8

Looking into your axiosClient you seem to be checking for exactly 'application/json' in order to set the parsedBody property of the response.

I know little about the rules of how content-type needs to be formatted. Is this a mistake on my server side, or is the axiosClient just being a little too stingy?

Such as minLength and pattern matching.

nyc is a good reporter and integrates well with typescript. It gives us good test coverage report.

"scripts": {
  "test": "nyc mocha ..."
   . . . 
}

The way the new URL Builder works/is utilized causes the base path to be completely replaced with the request path:

baseUrl: localhost:8080/api/23
path: /user/list
request: localhost:8080/user/list

desired request: localhost:8080/api/23/user/list

The tests under test/shared/serialization are very handy. However, it's hard to debug the failures because the stack trace doesn't indicate the location of the actual test. Requiring every serialization test to have a name would help a bit because I could at least ctrl+f to find the code for a failing test.

A method of test code reuse which still involves declaring tests with it("should work", async () => { ... }) syntax would also result in the stack trace showing the declaration site of the test which would be even more useful.

What do you think @daschult?

Previously, customers have complained that they find it difficult to provide a value for the discriminator property. Moreover they have argued that while declaring the model type if I am saying that it is a cat then why do you ask me to provide that information. Doesn't the sdk already know this?

Well that is actually true. The sdk knows this information but this info is in the model mapper. At runtime (i.e. in javascript that gets executed), the sdk gets a json object. We validate that json object against the model mapper that we know is associated for that operation. However, we would only know whether it is an Animal or a Cat or a Dog, based on what value the customer provides for the discriminator property.

Our model types are TypeScript Interfaces. We have chosen them to be interfaces over classes for multiple reasons. Typescript restricts us from providing default values for a property of an interface and it makes sense. However, that does not help us in solving the above problem faced by our customers.

Possible solutions that come to my mind are as follows:

• Ensure that the documentation of the discriminator property contains all the possible values in the documentation of that property. This will help customers who do not want to use TS.
• Create an enum of discriminator values. This allows us to map x-ms-discriminator values as value of the enum. The discriminator property is specified in every model with the possible value for that type.

export enum AnimalType {
  Animal = "Animal",
  Cat = "Cat",
  Dog = "Dog"
}
export interface Animal {
  type: AnimalType; // Here I have provided the enum as a type
  id: number;
  name: string;
}

export interface Cat extends Animal {
  type: AnimalType.Cat; // Here it is the specific type Cat
  weight: number;
}

export interface Dog extends Animal {
  type: AnimalType.Dog; // Specific type Dog
  color: string;
}

const a: Animal = {
  id: 1,
  name: "SomeAnimal",
  type: AnimalType.Animal // However one still needs to specify the type otherwise TS complains
}

const c: Cat = {
  id: 2,
  name: "BobCat",
  weight: 20,
  type: AnimalType.Cat // However one still needs to specify the type otherwise TS complains. Couldn't get TS to auto populate the value for type. However this is still better as it guides the customer to the right path.
}

• Create a type of possible discriminator values. For more context take a look over here.

export type AnimalType : "Animal" | "Cat" | "Dog".

export interface Animal {
  type: AnimalType;
  id: number;
  name: string;
}

export interface Cat extends Animal {
  weight: number;
}

export interface Dog extends Animal {
  color: string;
}

const a: Animal = {
  id: 1,
  name: "SomeAnimal",
  type: "Animal"
}

const c: Cat = {
  id: 2,
  name: "BobCat",
  weight: 20,
  type: "Cat"
}

• Make sure that the changes in ms-rest from 2.2.4 onwards are reflected in the TS runtime.

• Make sure that the changes in ms-rest-azure from 2.3.0 onwards are reflected in the TS runtime for azure.

• This is what the request library does. They have separate fields "form" and "formData" that need to be used based on the "Content-Type" in the request header.
  We have added a formDataFilter to the request pipeline in ms-rest (node sdk) to solve this issue.
• We are depending on the "fetch" library which does not have good support for this.
  • JakeChampion/fetch#263 and
  • matthew-andrews/isomorphic-fetch#30
    The above 2 issues should help us in finding the right solution.

I'm getting back a content type that includes encoding: application/json;charset=UTF-8.

This is failing the check in the axios client on @preview:

else if (contentType === "application/json" || contentType === "text/json" || !contentType)

I do not get parsed data back :|

I'm trying to load generated javascript by Autorest in the browser using "ms-rest-js" module instead of node.js specific "ms-rest". I get TypeError: this.getPackageJsonInfo is not a function when trying to call generated api client constructor in these lines (see Autorest node.js generated client sample):

let packageInfo = this.getPackageJsonInfo(__dirname);
this.addUserAgentInfo(`${packageInfo.name}/${packageInfo.version}`);

As I understand this is because my client code is generated by newer Autorest versions which "ms-rest-js" doesn't support yet. I see that testClient.ts file in this repo was generated by Autorest 0.14.0, but I can't understand how to generate my client using this old version. Autorest --version parameter only supports versions from 1.0.1 and even installing Autorest 0.14.0 from npm doesn't help - it automatically downloads and uses the latest version or fails with --version=0.14.0 parameter: AutoRest version '0.14.0' is not found in the releases feed.

Is it possible to generate api client with some old Autorest version that is supported by "ms-rest-js"?

Firefox 45 treats body === null differently from body === undefined

ms-rest-js setting the body to null leads to ta TypeError for GET and HEAD requests as it has to be undefined for firefox.

TypeError: HEAD or GET Request cannot have a body.
Stack trace:
zoneify/<@webpack-internal:///../../../../zone.js/dist/zone.js:1022:33
dispatchRequest/</<@webpack-internal:///../../../../ms-rest-js/dist/lib/util/utils.js:335:42
step@webpack-internal:///../../../../ms-rest-js/dist/lib/util/utils.js:34:18
verb/<@webpack-internal:///../../../../ms-rest-js/dist/lib/util/utils.js:15:53
__awaiter</<@webpack-internal:///../../../../ms-rest-js/dist/lib/util/utils.js:9:15
ZoneAwarePromise@webpack-internal:///../../../../zone.js/dist/zone.js:875:29
__awaiter<@webpack-internal:///../../../../ms-rest-js/dist/lib/util/utils.js:5:1
dispatchRequest@webpack-internal:///../../../../ms-rest-js/dist/lib/util/utils.js:293:1
RequestPipeline.prototype.requestSink@webpack-internal:///../../../../ms-rest-js/dist/lib/requestPipeline.js:47:16