Consider removing accepts dependency to reduce package size

[nfantone]

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?

[miwnwski]

We can only guess the actual usage of ctx.accepts, but the fact is that it's part of Koas public API so we have to assume it is used. Removing it would require a semver major. That being said, I know I use it - and I would argue that it is part of Koas domain to provide this functionality. The size of the dependency isn't really a practical metric in my opinion so I would advice not to remove it (now or in a future version). Others might disagree, let's keep this open and see what opinions comes.

[nfantone]

Removing it would require a semver major.

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.

That being said, I know I use it - and I would argue that it is part of Koas domain to provide this functionality.

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

The size of the dependency isn't really a practical metric in my opinion so I would advice not to remove it (now or in a future version).

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.

Koa is a new web framework designed by the team behind Express, which aims to be a smaller, more expressive, and more robust foundation for web applications and APIs. [...] Koa does not bundle any middleware within its core, and it provides an elegant suite of methods that make writing servers fast and enjoyable.

(from https://koajs.com)

[dead-horse]

As a backend framework, reduce package size is at a lower priority. :)

[nfantone]

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

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

[3imed-jaberi]

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

[jonathanong]

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.

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

[siakc]

I think judging by size percentage does not give a whole insight. It is ~121 KBs only. It is nothing.

[HonzaMac]

Is it possible to read "mimedb" from operating system via nodejs API?