-
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
Add TypeScript typings for tree-shakable version of the library #1442
Comments
➤ Automation for Jira commented: The link to the corresponding Jira issue is https://ably.atlassian.net/browse/SDK-3857 |
lawrence-forooghian
added a commit
that referenced
this issue
Nov 1, 2023
This adds a package script `test:package`, which performs some basic testing to confirm that a browser-based TypeScript app is able to import the NPM package and use Ably functionality. This hopefully gives us further confidence that we’ve correctly configured the package’s exports and typings. Next, we’ll build on top of this to add similar testing for the tree-shakable version of the library, once we’ve added typings for it in #1442.
lawrence-forooghian
added a commit
that referenced
this issue
Nov 1, 2023
This adds a package script `test:package`, which performs some basic testing to confirm that a browser-based TypeScript app is able to import the NPM package and use Ably functionality. This hopefully gives us further confidence that we’ve correctly configured the package’s exports and typings. Next, we’ll build on top of this to add similar testing for the tree-shakable version of the library, once we’ve added typings for it in #1442. Some of the approach here is copied from that used for testing the CDN bundle in the Spaces SDK (see commit fa95f9f there).
lawrence-forooghian
added a commit
that referenced
this issue
Nov 1, 2023
This adds a package script `test:package`, which performs some basic testing to confirm that a browser-based TypeScript app is able to import the NPM package and use Ably functionality. This hopefully gives us further confidence that we’ve correctly configured the package’s exports and typings. Next, we’ll build on top of this to add similar testing for the tree-shakable version of the library, once we’ve added typings for it in #1442. Some of the approach here is copied from that used for testing the CDN bundle in the Spaces SDK (see commit fa95f9f there). Resolves #1474.
lawrence-forooghian
added a commit
that referenced
this issue
Nov 8, 2023
This adds a package script `test:package`, which performs some basic testing to confirm that a browser-based TypeScript app is able to import the NPM package and use Ably functionality. This hopefully gives us further confidence that we’ve correctly configured the package’s exports and typings. Next, we’ll build on top of this to add similar testing for the tree-shakable version of the library, once we’ve added typings for it in #1442. Some of the approach here is copied from that used for testing the CDN bundle in the Spaces SDK (see commit fa95f9f there). Resolves #1474.
lawrence-forooghian
added a commit
that referenced
this issue
Nov 8, 2023
This adds a package script `test:package`, which performs some basic testing to confirm that a browser-based TypeScript app is able to import the NPM package and use Ably functionality. This hopefully gives us further confidence that we’ve correctly configured the package’s exports and typings. Next, we’ll build on top of this to add similar testing for the tree-shakable version of the library, once we’ve added typings for it in #1442. Some of the approach here is copied from that used for testing the CDN bundle in the Spaces SDK (see commit fa95f9f there). Resolves #1474.
lawrence-forooghian
added a commit
that referenced
this issue
Nov 13, 2023
I wasn’t sure of the best way to approach the typings of the modules (`Rest` etc). They should be opaque to the user (they shouldn’t be interacting with them directly and we want be free to change their interface in the future). There is an open issue to add support for opaque types to TypeScript [1], and people have suggested various sorts of ways of approximating them, which revolve around the use of `unique symbol` declarations. However, I don’t fully understand these solutions and so thought it best not to include them in our public API. So, for now, let’s just use `unknown`, the same way as we do for `CipherParams.key`. Resolves #1442. [1] microsoft/TypeScript#202
lawrence-forooghian
added a commit
that referenced
this issue
Nov 13, 2023
I wasn’t sure of the best way to approach the typings of the modules (`Rest` etc). They should be opaque to the user (they shouldn’t be interacting with them directly and we want be free to change their interface in the future). There is an open issue to add support for opaque types to TypeScript [1], and people have suggested various sorts of ways of approximating them, which revolve around the use of `unique symbol` declarations. However, I don’t fully understand these solutions and so thought it best not to include them in our public API. So, for now, let’s just use `unknown`, the same way as we do for `CipherParams.key`. Resolves #1442. [1] microsoft/TypeScript#202
lawrence-forooghian
added a commit
that referenced
this issue
Nov 14, 2023
I wasn’t sure of the best way to approach the typings of the modules (`Rest` etc). They should be opaque to the user (they shouldn’t be interacting with them directly and we want be free to change their interface in the future). There is an open issue to add support for opaque types to TypeScript [1], and people have suggested various sorts of ways of approximating them, which revolve around the use of `unique symbol` declarations. However, I don’t fully understand these solutions and so thought it best not to include them in our public API. So, for now, let’s just use `unknown`, the same way as we do for `CipherParams.key`. Resolves #1442. [1] microsoft/TypeScript#202
lawrence-forooghian
added a commit
that referenced
this issue
Nov 14, 2023
I wasn’t sure of the best way to approach the typings of the modules (`Rest` etc). They should be opaque to the user (they shouldn’t be interacting with them directly and we want be free to change their interface in the future). There is an open issue to add support for opaque types to TypeScript [1], and people have suggested various sorts of ways of approximating them, which revolve around the use of `unique symbol` declarations. However, I don’t fully understand these solutions and so thought it best not to include them in our public API. So, for now, let’s just use `unknown`, the same way as we do for `CipherParams.key`. Resolves #1442. [1] microsoft/TypeScript#202
lawrence-forooghian
added a commit
that referenced
this issue
Nov 14, 2023
This adds a package script `test:package`, which performs some basic testing to confirm that a browser-based TypeScript app is able to import the NPM package and use Ably functionality. This hopefully gives us further confidence that we’ve correctly configured the package’s exports and typings. Next, we’ll build on top of this to add similar testing for the tree-shakable version of the library, once we’ve added typings for it in #1442. Some of the approach here is copied from that used for testing the CDN bundle in the Spaces SDK (see commit fa95f9f there). Resolves #1474.
lawrence-forooghian
added a commit
that referenced
this issue
Nov 14, 2023
I wasn’t sure of the best way to approach the typings of the modules (`Rest` etc). They should be opaque to the user (they shouldn’t be interacting with them directly and we want be free to change their interface in the future). There is an open issue to add support for opaque types to TypeScript [1], and people have suggested various sorts of ways of approximating them, which revolve around the use of `unique symbol` declarations. However, I don’t fully understand these solutions and so thought it best not to include them in our public API. So, for now, let’s just use `unknown`, the same way as we do for `CipherParams.key`. Resolves #1442. [1] microsoft/TypeScript#202
Closed in #1498. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Expose typings for the tree-shakable version of the library added in https://ably.atlassian.net/browse/SDK-3719 — that is, the
BaseRest
andBaseRealtime
classes, as well as the tree-shakable modules such asRest
etc. And expand the testing added in #1474 to cover the tree-shakable version of the library.The text was updated successfully, but these errors were encountered: