search

drachtio / drachtio-srf

drachtio signaling resource framework
https://drachtio.org
MIT License
167 stars 58 forks source link

darchtio-srf types are not correctly exported using TS #181

Open hadar-laguna opened 4 days ago

hadar-laguna commented 4 days ago

in the update to 4.5.40 you added the namespace Srf and export = Srf.Srf; Which caused all of the other types (Dialog, SipResponse, SipRequest, CreateUACOptions and many more) to not be accessible.

Please fix this. Thanks!

davehorton commented 4 days ago

can you refer to the problematic commit that you see?

danvirsen commented 3 days ago

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: https://github.com/drachtio/drachtio-srf/pull/176

hadar-laguna commented 3 days ago

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

hadar-laguna commented 3 days ago

You should change it to 

    export = Srf;

and add options function inside the class Srf.

danvirsen commented 3 days ago

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

danvirsen commented 3 days ago

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

hadar-laguna commented 3 days ago

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!

danvirsen commented 3 days ago

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.

hadar-laguna commented 7 hours ago

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..

danvirsen commented 7 hours ago

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();
danvirsen commented 4 hours ago

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

I can give that a go on Monday.