can you refer to the problematic commit that you see?

Not OP, but I was in the process of updating drachtio-srf when I noticed this and found that there was an issue created only hours ago.

This is the PR: #176

Also, it seems the function "options" is missing from types (srf.options( ...))

You should change it to

    export = Srf;

and add options function inside the class Srf.

I created a new branch in my fork for this.
Could you please help me test? You should be able to just replace the version with the path in your package.json:

{
  "dependencies": {
    "drachtio-srf": "danvirsen/drachtio-srf#bugfix/181"
  }
}

If something is missing, feel free to make changes yourself.
A lot of methods have multiple overloads so it's completely possible that a couple are still missing.

I haven't checked out or added the "options" method yet.

https://github.com/danvirsen/drachtio-srf/tree/bugfix/181

I have added all missing (I hope) middleware methods for "srf".

Hey, So i checked it, and its still problematic since the typing is kind of "lying" as to the whole class.
export = Srf;
is not necessarily the solution, i don't have a lot of time, i will try to fix it later this week and update you, or someone else can try it!

Yes, that's true. I did the changes blind but when I tested my changes I did get some "implicit any type" errors and other warnings that some types weren't available. So things weren't exposed correctly.
I have adressed that now (I think) and pushed the changes, and my application is at least happy again.

The codebase is JavaSCript and since the types are managed manually they will always "lie" I suppose. They're not connected to the actual code in any way which make some things that aren't documented lag behind and only surface when someone wants to use a specific call or function/method.

It's a risk to have manually handled types in the repository. Intellisense will only show what the types contain, which like I said aren't actually connected to the code, so there's still the risk of runtime errors due to the types being wrong.

I'm not sure if there is a good way to try and automate this.

One solution might be to simply remove the types, but they do contain a couple of ondocumented ways to call certain methods so I do think they add some value.

looks good!
working for me as such:

import * as Srf from 'drachtio-srf';
import { CreateUACOptions, Dialog, SrfRequest, SrfResponse } from 'drachtio-srf';

  // eslint-disable-next-line
  // @ts-ignore
const srf: Srf.default = new Srf();

its not the most typescripty but it works..

Since the default export is the class Srf, I use it like this:

import Srf, { CreateUACOptions, Dialog, SrfRequest, SrfResponse } from "drachtio-srf";
const srf = new Srf();

I was thinking that it might make sense to move the types to the DefinitelyTyped project instead of having them in this repository.

https://github.com/DefinitelyTyped/DefinitelyTyped

Until then hopefully my PR fixes the issues we are having for now.

Proposed fix:

• Types: Fix importing non-default types #185

I have added a comment to your PR but overall I think it looks good.
The bigger question still remains for me though: Should the types be in this repository at all?

I think the best thing would be to add drachtio-srf to DefinitelyTyped and remove the types from this repository. That way Dave and the other maintainers don't need to be bothered with TypeScript things (this is a JavaScript project after all), and fixes to the types themselves doesn't require getting a PR approved and waiting for a new release of the package.

Unfortunately I don't have time in the nearest future to create a valid test suite for drachtio-srf in the DefinitelyTyped project. I think that would be the best solution if anyone has the opportunity to do that.

@davehorton what do you prefer? Keep the types here or create a package in DefinitelyTyped?