Consider removing `accepts` dependency to reduce package size

Taking a look at the published koa@2.13.0 bundle shows that mime-db takes up almost 62% of koa total size.

mime-db comes as a transitive dependency from accepts.

❯ npm ls mime-db
@my-project@1.0.0 /dev/my-project
└─┬ koa@2.13.0
  └─┬ accepts@1.3.7
    └─┬ mime-types@2.1.27
      └── mime-db@1.44.0 

Your experience and mileage may, obviously, vary - but I’ve been using koa (and derivatives such as apollo-server-koa) extensively for a number of years now, in almost all of my web based projects, and I believe I have only once used ctx.accepts or any of the other public API features related to accepts. 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?

[nfantone]

@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.

this would be difficult because a lot of other middleware use it

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.

there’s a good a chance another dependency in your tree uses mime-db as well.

Probably. Probably not. We can’t really make assumptions on users’ environments. Regardless, if a user installs mime-db (either explicitly or through a transitive dep), that’s really on them.

Honestly, all I wanted to do is raise awareness on how much koa allocates to a functionality that feels completely secondary next to its core. This, IMHO, goes against koa’s own principles. Specially, since it can very easily be stripped out and made available as a different, optional package.

I would love to see koa v3 be published as a simple, barebones middleware engine and thin wrappers around the native http Node.js module. Everything else should be optional.

[nfantone]

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:

• express (404.9kB) sees a whooping 67% of its size taken by mime-db and iconv-lite.
• hapi (404.9kB) reserves almost half (!) of its size to both mime-db and joi - providing second-hand features for raw web frameworks.

On the other hand,

• fastify (347.9kB, smaller) does not bundle mime-db at all, but still depends on ajv for its famed “fast JSON stringify” which takes up about 27% of the total bundle size.