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

[feat] Switch to undici (PR welcome) #1763

Open
titanism opened this issue Feb 23, 2023 · 5 comments
Open

[feat] Switch to undici (PR welcome) #1763

titanism opened this issue Feb 23, 2023 · 5 comments

Comments

@titanism
Copy link
Collaborator

We'd like to switch to use undici instead of http and https packages. The performance difference is staggering and it would make superagent one of the only userland wrappers that use it under the hood.

@titanism titanism changed the title [feat] Switch to undici [feat] Switch to undici (PR welcome) Feb 23, 2023
@titanism
Copy link
Collaborator Author

This would be a major semver bump and large rewrite.

@jimmywarting
Copy link
Contributor

👍 for this!

Looking at the dependency graph: https://npmgraph.js.org/?q=superagent@8.1.2
i see things like formidable and form-data

it would be nice to replace them with undici or NodeJS FormData stuff.
parsing formdata could be as simple as using Response/Request.formData() all doe you get a FormData back along with File instances that are real web stuff

@titanism
Copy link
Collaborator Author

yeah it would be amazing to have all functionality of superagent (e.g. retrys) on top of undici

@jimmywarting
Copy link
Contributor

jimmywarting commented Aug 18, 2023

Could you maybe create a new brach?

i would expect there to be kind of many breaking changes...

  • require at least NodeJS v16.8 (required by undici)
  • build things using fetch, FormData, Blob, File, Response, Request
  • dropping total support for XHR and only using fetch
    • that could mean that it would also work in service workers
    • Node runtime could use pretty much the same codebase
  • maybe this could be switched to ESM syntax?
  • if XHR and http(s) gets replaced with fetch then we also loose progress monitoring
  • things like this won't work anymore:
.on('request', function () {
  this.xhr.responseType = 'arraybuffer';
})

it's going to be a Request instead or a Request-like object so that it can be modified before initiating a fetch call so cache and other can be modified.

I could expect blob/files could be used on the backend as well along with FormData
NodeJS just recently introduced const blob = await fs.openAsBlob(path, { type })
but there is no sync method, and it only works in NodeJS v20+

to solve this problem then fetch-blob could be used instead. but it's ESM-only
so loading it would be hard unless this pkg dose not also becomes ESM enabled.

another approch would be to import fetch-blob async using import()
then attach() would kind of have to queue up all those path -> Blob conversions.

or we would have to read the files content sync and create a Blob in memory...

@titanism
Copy link
Collaborator Author

@jimmywarting this all sounds amazing. we just gave you collab access to the entire @ladjs org.

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

No branches or pull requests

2 participants