denoland
suggestion: make `@std/http` utilities cross-runtime
Is your feature request related to a problem? Please describe.
I would like to use @std/http/negotiation in Node using pnpm. negotiation is entirely self-contained, but jsr marks the whole @std/http module as Deno- and Bun-compatible only.
From a cursory look, most other utilities in @std/http (cookies, user_agent, status, server_sent_event_stream, ...) are also self-contained.
The dependencies for @std/http are from:
- unstable_signed_cookie depending on
@std/encoding - etag depending on
@std/encoding - unstable_file_server depending on
file_server(below) - file_server imports all the rest:
@std/path,@std/fs,@std/media-types,@std/streams,@std/cli,@std/fmt,@std/net,@std/html, and./etagabove
There has been efforts in making some @std modules cross-runtime compatible (but from what I could find there is no global guideline on that):
- https://github.com/denoland/std/issues/6255 (currently pinned)
- https://github.com/denoland/std/issues/4313 (referenced in the above)
- https://github.com/denoland/std/issues/6164
- https://github.com/denoland/std/issues/4914
- https://github.com/denoland/std/issues/4600
(search keywords: "cross-runtime", "node compatible")
The dependency graph in that last issue is relevant here:
http was the "widest" package dependency-wise, mostly from file_server.
The specific utility I want to use (negotiation) has been adapted from npm:negotiator, which has an open issue for migrating it to ES6: https://github.com/jshttp/negotiator/issues/71. Since the work has already been done here, being able to use @std/http/negotiation from any runtime would also solve that issue.
Describe the solution you'd like
Some obvious solutions would be to split file_server to it's own module, or abstracting the Deno-specific APIs like what has been discussed in https://github.com/denoland/std/issues/4313.
If it's possible to "install" a specific path inside a module like @std/http/encoding from other package managers (I use pnpm), that'd work too. I couldn't find anything about that (I don't know the right keywords to search for), but I assume this has been considered and decided against, since running deno add jsr:@std/http/negotiation installs jsr:@std/http. Doing pnpm i jsr:@std/http/negotiation errors with a 404.
Having a blessed path to vendor specific files or functions (either from @std or from jsr generally) would also solve it for me. But I figure that'd be very package-specific and couldn't be generalized without a lot of tooling work. (I couldn't find much about vendoring related to jsr or @std.)
Describe alternatives you've considered
My current solution is to simply manually vendor the functions that I need. Ignoring file_server, this also avoids me the dependency on @std/encoding (from etag and unstable_signed_cookie) which I don't use.
I have considered using vendoring tools (vendorpull, vendir, git-vendor), some of which have options to pick specific files or ignore other paths.
Simply installing the whole http module via pnpm i jsr:@std/http also works (even if the module's jsr page doesn't show the pnpm option). Given that I don't use file_server, I won't hit the Deno-specific code. But this makes me pull 11 transitive dependencies that I don't use.
Assumedly I focus a lot on reducing dependencies. I understand that it might not be a goal or focus for everyone (or for jsr, or for @std — especially since the dependencies are on other @std modules only!)
Thanks for your time (and for the work on @std)!
Actually (since the utilities are already cross-compatible afaik), maybe a simpler solution is to mark the whole module as compatible and add a note about file_server, like how it has been done for @std/fmt here: https://github.com/denoland/std/issues/6647
Sorry, I somehow missed that issue when searching earlier!