deno_std
deno_std copied to clipboard
feat(http/unstable): `unstable-file-server`
This new module is an updated version of @std/http/file-server that uses deno serve, which takes care of the heavy lifting of some argument parsing and can be run in parallel service workers thanks to --parallel. It directly relies on the exported symbols of @std/http/file-server and a few kinks need to be figured out.
Closes #5681
Codecov Report
Attention: Patch coverage is 53.33333% with 28 lines in your changes missing coverage. Please review.
Project coverage is 94.08%. Comparing base (
9195573) to head (6ce9184).
| Files with missing lines | Patch % | Lines |
|---|---|---|
| http/unstable_file_server.ts | 53.33% | 28 Missing :warning: |
Additional details and impacted files
@@ Coverage Diff @@
## main #6668 +/- ##
==========================================
- Coverage 94.69% 94.08% -0.62%
==========================================
Files 562 561 -1
Lines 46646 41661 -4985
Branches 6569 6558 -11
==========================================
- Hits 44173 39197 -4976
+ Misses 2430 2416 -14
- Partials 43 48 +5
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
:rocket: New features to boost your workflow:
- :snowflake: Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
- :package: JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.
The entrypoint name seems suggesting this will be merged to file-server in the future, but I don't think we can do that (this script only work with deno serve, not with deno run)
Maybe better to give a different name?
Yes, I should've clarified that my intention was that this was to replace the current @std/http/file-server. My reasoning is that it's worth the breakage thanks to deno serve doing the heavy lifting of CLI argument parsing and the ability to parallelise requests with deno serve --parallel. Though, I know I'm more liberal with breaking changes than most.
Alternatively, we can depend on https://github.com/denoland/deno/issues/29447 to be implemented as to minimise breaking changes and avoiding having to create a new endpoint.
I'll take another approach if https://github.com/denoland/deno/pull/29812 is merged.