-
Notifications
You must be signed in to change notification settings - Fork 56
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
Sort out the false class exports in our type declarations #1519
Comments
➤ Automation for Jira commented: The link to the corresponding Jira issue is https://ably.atlassian.net/browse/SDK-3967 |
lawrence-forooghian
added
bug
Something isn't working. It's clear that this does need to be fixed.
breaking
Backwards incompatible changes made to the public API.
labels
Nov 30, 2023
lawrence-forooghian
added a commit
that referenced
this issue
Dec 4, 2023
The type declarations claim that the SDK exports all manner of classes that it does not in fact export, such as Auth, Presence, PushAdmin, AbstractRest, AbstractRealtime etc. Trying to import these classes will result in a runtime (or bundler) error. So, we convert them all to interfaces. (I can’t see an obvious downside of doing this; let me know if there is.) Resolves #1519.
lawrence-forooghian
added a commit
that referenced
this issue
Dec 4, 2023
The type declarations claim that the SDK exports all manner of classes that it does not in fact export, such as Auth, Presence, PushAdmin, AbstractRest, AbstractRealtime etc. Trying to import these classes will result in a runtime (or bundler) error. So, we convert them all to interfaces. (I can’t see an obvious downside of doing this; let me know if there is.) I’ve also addressed the ClientOptions docstring’s links to the Abstract* constructors by rewording their text, since these links are now completely broken (they were previously linking to a useless entry for a nonexistent constructor). Resolves #1519, resolves #1520.
lawrence-forooghian
added a commit
that referenced
this issue
Jan 4, 2024
The type declarations claim that the SDK exports all manner of classes that it does not in fact export, such as Auth, Presence, PushAdmin, AbstractRest, AbstractRealtime etc. Trying to import these classes will result in a runtime (or bundler) error. So, we convert them all to interfaces. (I can’t see an obvious downside of doing this; let me know if there is.) I’ve also addressed the ClientOptions docstring’s links to the Abstract* constructors by rewording their text, since these links are now completely broken (they were previously linking to a useless entry for a nonexistent constructor). Resolves #1519, resolves #1520.
lawrence-forooghian
added a commit
that referenced
this issue
Jan 15, 2024
The type declarations claim that the SDK exports all manner of classes that it does not in fact export, such as Auth, Presence, PushAdmin, AbstractRest, AbstractRealtime etc. Trying to import these classes will result in a runtime (or bundler) error. So, we convert them all to interfaces. (I can’t see an obvious downside of doing this; let me know if there is.) I’ve also addressed the ClientOptions docstring’s links to the Abstract* constructors by rewording their text, since these links are now completely broken (they were previously linking to a useless entry for a nonexistent constructor). Resolves #1519, resolves #1520.
Resolved by #1524. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
(This issue is written with respect to the state of the type declarations after the changes made in #1518, but it applied equally before those changes, too.)
The type declarations claim that the SDK exports all manner of classes that it does not in fact export, such as
Auth
,Presence
,PushAdmin
,AbstractRest
,AbstractRealtime
etc. Trying to import these classes will result in a runtime (or bundler) error.We should fix this.
My suggestion would be to change these classes to interfaces. I think that only place where this will present a bit of a problem is with
AbstractRest
andAbstractRealtime
; if we change those to interfaces then we'll have to copy all of their method declarations to theRest
andRealtime
class declarations inably.d.ts
, and theBaseRest
andBaseRealtime
class declarations inmodules.d.ts
. That in itself is not much of an issue, but I’m not sure whether we'd also have to copy all of the documentation comments as well, or whether they'd somehow be inherited (would need to check the behaviour in TypeDoc and also in IntelliSense e.g. in VS Code). We'd also need to consider what to name them; theAbstract
prefix probably wouldn't make sense any more, but we can't just call themRest
andRealtime
because that clashes with the exports ofably.d.ts
. Would we need to stick the wordI
orInterface
in there somewhere?The text was updated successfully, but these errors were encountered: