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

Make this module up-to-date and to the Fastify standard #2

Closed
mcollina opened this issue Jan 11, 2023 · 12 comments
Closed

Make this module up-to-date and to the Fastify standard #2

mcollina opened this issue Jan 11, 2023 · 12 comments
Assignees
Labels
good first issue Good for newcomers

Comments

@mcollina
Copy link
Member

This module was forked due to fastify/fastify-static#352.

Given the status of maintenance of send() and how badly out of date it was in its deps, I think we could do some good work here to bring this module up to our standards.

@mcollina mcollina added the good first issue Good for newcomers label Jan 11, 2023
@Fdawgs Fdawgs mentioned this issue Jan 11, 2023
2 tasks
@Uzlopak
Copy link
Contributor

Uzlopak commented Jan 12, 2023

Can somebody please add this repo to @fastify/libraries please?

@mcollina mcollina self-assigned this Jan 12, 2023
@Uzlopak
Copy link
Contributor

Uzlopak commented Jan 12, 2023

Should we remove all the deprecated functions and options?

@mcollina
Copy link
Member Author

Yes

@jsumners
Copy link
Member

Can somebody please add this repo to @fastify/libraries please?

Done.

@Uzlopak
Copy link
Contributor

Uzlopak commented Jan 15, 2023

Is refactoring part of this issue?

We got already

  • use of our workflows
  • use standardjs
  • use tap as test runner
  • 100% code coverage
  • support of lts versions of node

What left is

  • Refactor to remove the need for a PassThrough stream #15
  • maybe remove all those packages which are made for streams issue of node 0.8.0 like on-finished, destroy
  • maybe remove http-errors package as it is in my benchmarks a performance bottleneck
  • integrate some of the dependencies like fresh and range
  • general perf optimizations
  • check if we can take open PRs of the original send repo

@mcollina
Copy link
Member Author

I'd be ok to cut a v2 without #15, and then work on a v3 for it.

@Uzlopak
Copy link
Contributor

Uzlopak commented Jan 16, 2023

After #27 we could integrate parseRange and fresh package.

@Uzlopak
Copy link
Contributor

Uzlopak commented Jan 18, 2023

Imho all relevant pieces are now in the repo. We could start transplanting open PRs from the original repo to our fork. But maybe @climba03003 wants to implement #15 ?

@mcollina
Copy link
Member Author

#15 is super important.

@mcollina
Copy link
Member Author

I think we can close this.

@mcollina
Copy link
Member Author

Should we release v2?

@climba03003
Copy link
Member

Should we release v2?

Yes, #15 would completely change the API. And v2 should be compatible to the original one.

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

No branches or pull requests

4 participants