Don't be a pain in the ass for node community

[broofa]

All, I've been a bit of an absentee landlord as far as maintaining this library goes. My response time on issues has been horrid, and that https://github.com/jshttp/mime-types exists is testament to the poor job I've been doing. For this I humbly apologize.

Moving forward, I'd like to insure this isn't an issue. So... What's the right thing to do here? Are there parties interested in being added as maintainers? (If so, who?) Should this library be deprecated in favor of mime-types? Could mime-types be pulled in here?

Hopefully I haven't completely alienated everyone. I'm genuinely interested in hearing everyone's opinions, and willing to do whatever the community thinks is best.

cc: @dominictarr @Fishrock123 @substack @jonathanong

[Fishrock123]

Apologies accepted, no worries. :)

I wouldn't say mime-types exists solely because it was not updated. The goal was to avoid the new Mime() API also.

I would give mime-types a good look over; nowadays it works somewhat differently than mime.

Specifically, everything is built on top of mime-db. Which you may also want to look at. (It is a very comprehensive and api-neutral types database, to the point that even hapi uses it.)

cc @dougwilson also

[Fishrock123]

Should this library be deprecated in favor of mime-types?

That is up to you.

Could mime-types be pulled in here?

In the interest of community control + openness, we would keep mime-types in jshttp (a multiple-owner github org). Minus the fact that the API is different of course. :)

[jonathanong]

happy thanksgiving! some options are:

• bump the major version, deprecate, and simply module.exports = require('mime-types')
• use mime-types while attempting to keep backwards compatibility

these are the only solutions i can think of. we won't be abandoning mime-types.

[dougwilson]

In addition, no one says there cannot be two mime type libraries...

[Fishrock123]

@broofa Again, the API is different. If anything, I'd recommend using mime-db as the types database.

[broofa]

@Fishrock123 Given that the original motivation of #61 was to make this compatible with Browserify (i.e. run in-browser), does it really make sense to switch to mime-db? The mime-db data has a lot of empty entries (entries with no extensions info). Also, how is the source property used? 'Seems like that's probably not very interesting to most people. Sorry, not trying to be critical of mime-db... just trying to understand what the actual issues are here, and how we can add the most value across the respective modules.

[Fishrock123]

mime-bd is just json, and thus browserify compatible. Source is a little silly imo, but the rest is far more comprehensive than the DB here.

You could always do a build here that only leaves types with extensions and strips the rest. :)

[broofa]

You could always do a build here that only leaves types with extensions and strips the rest. :-)

mime-db's extension data just comes from Apache, and the node.types file I maintain in this repo, no?

Circular dependencies make me dizzy. ;)

[dougwilson]

mime-db's extension data just comes from Apache, and the node.types file I maintain in this repo, no?

It comes from three sources:

1. Apache
2. IANA registry
3. This repo :) mainly because you had all the user-contributed listings and we just wanted to use yours

I'm just answering this, but I really have no opinion about what happens here. I don't see any true reason why there cannot be two different mime libs. If this library were to start using mime-db, though, all the custom stuff from #3 will need to be moved somewhere else, though, so there isn't a circle.

[Hypercubed]

I'm interested (and created: https://github.com/Hypercubed/node-mime) a library that can do this:

var MimeLookup = require('mime');
var mime = new MimeLookup({ /* my own definitions */ });

https://github.com/jshttp/mime-types cannot do that and has mime-db as a dependency. My proposal is to split the module into two parts (see #129).

[Hypercubed]

FYI: https://github.com/Hypercubed/mime-lookup

[docunext]

Why do you, @broofa, have to be the only author of node-mime? I find the points presented by @Fishrock123 and @dougwilson to be surprisingly level-headed, specifically the point that multiple mime libraries can happily co-exist. On the flip side, I agree with your point about mime-db - to me its abstraction for the sake for abstraction. Actually, reading further, @dougwilson's reply is spot on, again!

Anwyay, I'm glad I stopped by! mime-types looks to have what we needed with the PR @loudwinston made in #136

While we don't need what @Hypercubed adds, and I'm not too keen on the general concept of the proliferation of mime-types, release valves (a term I just learned from @loudwinston) are awesome because its not cool to make it harder for developers to do what they need to.

UPDATE: I had originally included "when appropriate" to describe release valves in the context of adding custom mime types, and regret the removal. Because: https://github.com/jshttp/mime-db#adding-custom-media-types

[Hypercubed]

@docunext I'm not sure what you mean by valves. My proposal in #129 was to separate the lookup API from the mime-db itself, it had nothing to do with adding types. The mime-db large. If I use node-mime in the browser, and I did for some time, it to too much to send over the wire. https://github.com/Hypercubed/mime-lookup is a fork of node-mime that provides just the API. The database can be then entire mime-db (https://github.com/Hypercubed/mime-lookup#using-mime-db) or a subset as I have done here: https://github.com/Hypercubed/Project-Chi/blob/master/app/common/services/datapackage/mime.js

[broofa]

Hey all, thanks for the comments and, more importantly, your patience.

@docunext - I don't have to be the only contributor to this repository. It's more that there's never really been an obvious person to hand responsibility off to. I'm open to suggestions, especially if you have someone in mind who has a demonstrated ability to responsibly shepard a library that a lot of projects depend on.

[Hypercubed]

Hello @broofa,

is the difficulty maintaining the mime database or the repo itself. I think my proposal in #129 could help.

[broofa]

Closing this out as node-mime is sits on mime-db now.