`.mov` vs `.qt` about mime-db HOT 9 CLOSED

There is no significance to the order of extensions in the array. For this particular example, they are simply listed in the same order as they are in the Apache source they come from (https://svn.apache.org/repos/asf/httpd/httpd/trunk/docs/conf/mime.types).

from mime-db.

@dougwilson thank you for the response, however there are projects that uses the array and takes the first element and calls it a day, they won't change, this won't change. So I guess will need to raise this with apache then?

from mime-db.

I guess? I mean, I can modify the code here to sort them alphabetically, but who knows what collateral damage that would cause if what you assert is true...

from mime-db.

@dougwilson cool, would you be willing to merge a PR with a single entry change? Will there be a build process that gets overwritten?

I also don't think a batch process to make everything alphabetical like that is a good idea.

from mime-db.

The db.json file is not hand-curated: it is a build process that pulls the data from the three sources listed at the top of the readme and merges the data into that file. The goal of the project is zero hand-curation, as it would be too immense, and not something I signed up for :) Whatever change to the build project needs to just be a generic change, which is why I suggested alpha-ordering extensions array.

from mime-db.

as it would be too immense, and not something I signed up for

As it is an open-source project, the community, also the users of this project can help out also :)

from mime-db.

I understand that, and appreciate the offer, but I have been going this for 10 years. I cannot even count on the number os similar offers and they always drop off... I suggest perhaps making a project that does that and publishing to npm? I can even point folks there who are looking for hand-curated lists and you're welcome to deal with the endless issues and arguments that come with that (which is the main reason I won't go back to doing that again here).

from mime-db.

Sounds like it will be rough to have a fork, just only really wanted to resolve a package from a 3rd party. Anyways for those who are looking at a similar issue, can use a feature called patch fromyarn https://yarnpkg.com/cli/patch and pnpm https://pnpm.io/cli/patch

from mime-db.

Well, it just depends on what you want to do. For example, you don't need to fork pre-se. Perhaps a file in the repo with the list of overrides, similar to the patch idea above and then it either uses this module as a dependency or uses a build process to pull the data, merges them together and that's the export. Of course, anything you don't adjust by hand is suspectable to change suddenly, so I can't image it truly being useful without someone going through every single entry with more than one extension and researching which one is the "primary" one...

from mime-db.