-
-
Notifications
You must be signed in to change notification settings - Fork 3.2k
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
Consider removing accepts
dependency to reduce package size
#1508
Comments
We can only guess the actual usage of |
I agree. There are already plans and a roadmap for v3. I don't see this as a big deal if we clearly document a path forward and alternatives. That's exactly what semver is for, I believe.
I don't use it as much, but I understand where you are coming from. Not quite convinced on being Koa's core responsibility to provide such functionality, though. It's obviously subjective and up for debate. But there are already dozens of first and third party middlewares out there providing features that we could argue fall right into "Koa's domain" and are not bundled within
This is a fair opinion. I don't necessarily see it the same way, however. With the current shift towards serverless infrastructure, there's an increasing need for lean packages. And while I agree size might not be a relevant metric outside these areas, it's how much of it is allocated to a dubious purpose, to say the least, what calls my attention. For a framework that tries to explicitly market itself as "not bundling anything other than the bare minimum", it raises a flag (for me) that 62% of it is dedicated to something I very rarely feel the need for. Being small is one of the few Koa's core values.
(from https://koajs.com) |
As a backend framework, reduce package size is at a lower priority. :) |
@dead-horse I agree: it's lower. I also see this as low hanging fruit that would yield an enormous return in terms of reducing Koa's footprint, core size and overall bug surface. 62% percent is a bit unreasonable, in my opinion. |
I could try and open a PR for this if people would consider taking a stab at it or if there's any interest in it. This could also become a "selling point" for Koa. Web frameworks that have been around for longer all seem to suffer from the same software bloating:
On the other hand,
|
IMHO, it's the time to think of the next release and write a ref focus on improving performance and reducing the bundle size or update the current one #1114 |
are you more concerned with the disk size or app startup time? if the latter, we can lazy load it. if you're just worried about disk size, this would be difficult because a lot of other middleware use it and there's a good a chance another dependency in your tree uses mime-db as well. |
@jonathanong Both, really. On serverless environments both aspects should be considered. Lazy loading it could be a first good step, but I'm concerned it'd break some bundlers out there.
We can temper difficulties by introducing this as a major release. I think this was mentioned before here. This is exactly why we follow SemVer. I don't see it as a real setback.
Probably. Probably not. We can't really make assumptions on users' environments. Regardless, if a user installs Honestly, all I wanted to do is raise awareness on how much I would love to see |
I think judging by size percentage does not give a whole insight. It is ~121 KBs only. It is nothing. |
Is it possible to read "mimedb" from operating system via nodejs API? |
Taking a look at the published
[email protected]
bundle shows thatmime-db
takes up almost 62% ofkoa
total size.mime-db
comes as a transitive dependency fromaccepts
.Your experience and mileage may, obviously, vary - but I've been using
koa
(and derivatives such asapollo-server-koa
) extensively for a number of years now, in almost all of my web based projects, and I believe I have only once usedctx.accepts
or any of the other public API features related toaccepts
. IMHO, for something that offers very little in terms of aiding regular users in building robust web servers and covers a really small part of the API surface, letting it take more than half the size of the entire framework seems very disproportionate - not to mention, unnecessary.It might be required internally, as a core component, so I'm not sure about the feasibility of stripping
accepts
. I doubt, however, that the effort to remove it altogether (or replace it with a slimmer version?) would not pay off in the end. If really needed, users could install it on their own.accepts
could be turned into a middleware of sorts, even.Thoughts?
The text was updated successfully, but these errors were encountered: