Remove compressible for db 2.0

[dougwilson]

Since we defined the 1.0 of the mime-db it has worked well, expect for one of the properties: compressible. This property cannot be derived from the upstream data and instead rules must live in this repo to populate the value. By itself, this is not too bad, but it adds additional complexity to the module as well as inflates the size of the database for something many may not even use.

I'm thinking that a 2.0 version should drop this property from the database format and all related rules from this module.

The compressible data and ruleset would live on still, under the npm module compressible. Instead of delegating to this module for compressible data, it would instead be the store of all the rules (and would not even need to depend on this module).

I'm opening this up for thoughts on this proposal, especially for those who are dependent on the database format. I'm not planning to make any changes for quite some time. Perhaps in a few months at the earliest, so there is plenty of time for feedback to fall here, if any.

[Fishrock123]

Heh, guess it kinda makes sense.

That being said I think we'll just end up having like compressible-db or something, because I'm pretty sure we'll just end up needing another giant JSON blob.

Maybe it's better to do more sniffing for text / text-related encodings in the data itself. I dunno.

[bjohansebas]

I really like this idea. I offer to volunteer to do this work if it's alright with you, it would help avoid breaking packages like compression.

cc: @jshttp/express-tc

[wesleytodd]

Good find on this issue, I had not seen this one. I agree it would be good to change, but this will take a long time to roll out properly (since this is a more commonly directly depended on package and is also in the express dep tree. I would guess we want to work out a full plan for what we would want to land in a 2.0, and I think ideally it would include decoupling the semverness of the data from the semverness of our api contract. So 👍 for working on this, but lets not try to cut a 2.0 until we have also solved for that other issue.

[bjohansebas]

Great, maybe you want to create a new repository for this so we can work on it over the next few months.

[wesleytodd]

I don't think we need a new repo. We can do it in forks or branches right? Or did you have something else in mind?

[bjohansebas]

Well, since the compressible field was planned to be removed, another package is still needed that includes the mimes that are compressible (since it will require compression and other packages that depend on them), that's why I mention creating the repository.

Obviously, version 2 of this package will be done in a pull request.

[wesleytodd]

since it will require compression and other packages that depend on them

Based on the OP I assumed the intent was to move that data into compression. Does that work for you?