Skip to content
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

Closed
lawrence-forooghian opened this issue Sep 19, 2023 · 2 comments
Closed
Assignees

Comments

@lawrence-forooghian
Copy link
Collaborator

lawrence-forooghian commented Sep 19, 2023

Expose typings for the tree-shakable version of the library added in https://ably.atlassian.net/browse/SDK-3719 — that is, the BaseRest and BaseRealtime classes, as well as the tree-shakable modules such as Rest etc. And expand the testing added in #1474 to cover the tree-shakable version of the library.

@sync-by-unito
Copy link

sync-by-unito bot commented Sep 19, 2023

➤ 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
@lawrence-forooghian
Copy link
Collaborator Author

Closed in #1498.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

1 participant