Skip to content
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

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

Closed
broofa opened this issue Nov 27, 2014 · 16 comments
Closed

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

broofa opened this issue Nov 27, 2014 · 16 comments

Comments

@broofa
Copy link
Owner

broofa commented Nov 27, 2014

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
Copy link

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
Copy link

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
Copy link

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
Copy link

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

@Fishrock123
Copy link

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

@broofa
Copy link
Owner Author

broofa commented Nov 29, 2014

@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
Copy link

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
Copy link
Owner Author

broofa commented Nov 30, 2014

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. ;)

@broofa broofa closed this as completed Nov 30, 2014
@broofa broofa reopened this Nov 30, 2014
@dougwilson
Copy link

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
Copy link

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
Copy link

@docunext
Copy link

docunext commented Apr 28, 2016

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
Copy link

@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
Copy link
Owner Author

broofa commented May 2, 2016

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
Copy link

Hello @broofa,

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

@broofa
Copy link
Owner Author

broofa commented Jun 15, 2017

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants