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 generic type for opaque object for stream() and pipeline() #3378

Closed
jfhr opened this issue Jun 28, 2024 · 2 comments · Fixed by #3385
Closed

Add generic type for opaque object for stream() and pipeline() #3378

jfhr opened this issue Jun 28, 2024 · 2 comments · Fixed by #3385
Labels
enhancement New feature or request

Comments

@jfhr
Copy link
Contributor

jfhr commented Jun 28, 2024

This would solve...

Currently, when using stream() or pipeline(), opaque is typed as unknown in the callback, e.g:

const bufs = [];

undici.stream("https://example.com", {
    method: 'GET',
    opaque: { bufs }
}, ({ statusCode, headers, opaque }) => {
    // TypeError here: Property 'bufs' does not exist on type 'unknown'.ts(2339)
    const { bufs } = opaque;
    return new Writable({
        write(chunk, encoding, callback) {
            bufs.push(chunk)
            callback()
        }
    })
});

Checking this code with TypeScript will generate an error: Property 'bufs' does not exist on type 'unknown'.ts(2339)

If opaque was defined as generic, TypeScript could infer the type from the second argument to stream() and provide the correct type inside the callback.

The implementation should look like...

Add a generic type parameter (<TOpaque = null>) to the stream() and pipeline() type declarations as well as to RequestOptions and a few other interfaces. For example:

declare function stream<TOpaque = null>(
  url: string | URL | UrlObject,
  options: { dispatcher?: Dispatcher } & Omit<Dispatcher.RequestOptions<TOpaque>, 'origin' | 'path'>,
  factory: Dispatcher.StreamFactory<TOpaque>
): Promise<Dispatcher.StreamData>;

I have also considered...

The alternative is to keep the current type declarations and require users to always cast opaque to a certain type before using it.

Additional context

@Ethan-Arrowood , who originally added the type declarations, said in his pull request:

For simplicity, I'm keeping this as unknown. Using a generic to pass through a type is no safer than type casting an unknown value.

Maybe I'm missing something here, but it seems to me that the generic approach is safer because it enforces that the opaque object that was passed in the request options has the same type as the one received in the callback. For example, the following would currently only cause a runtime error, but with the generic approach would give a type error:

const bufs  = [];

undici.stream("https://example.com", {
    method: 'GET',
    // forgot to pass opaque
}, ({ statusCode, headers, opaque }) => {
    // error: opaque is null here
    const { bufs } = opaque;
    return new Writable({
        write(chunk, encoding, callback) {
            bufs.push(chunk)
            callback()
        }
    })
});
@jfhr jfhr added the enhancement New feature or request label Jun 28, 2024
@KhafraDev
Copy link
Member

Would you like to send a PR for this? Remember to add a test.

@jfhr
Copy link
Contributor Author

jfhr commented Jun 29, 2024

Ok, I will send a PR for this

jfhr added a commit to jfhr/undici that referenced this issue Jul 2, 2024
This adds a `TOpaque` generic type parameter to the type definitions
for request(), connect(), stream(), and pipeline(). The type parameter
defaults to null, which is the default value of the opaque property.
If an opaque value is passed in the options, its type can usually be
inferred automatically, such that no explicit type declaration is
necessary. This commit also adds tsd tests to make sure the type
definitions work as expected.

Previously, the type of `opaque` was `unknown`, which means it needed
to be either type-checked or casted to another type before anything
could be done with it. Such code should not be broken by this commit,
although some type checks or assertions might become redundant. Code
that disabled type checks (e.g. by casting to `any` or using
`@ts-ignore` should be unaffected. Code that does not use typescript
at all is also unaffected.

This closes nodejs#3378
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants