jshttp / mime-types Goto Github PK

When I do this; mime.contentType(mime.extension('audio/wave')), it returns 'audio/wave'. Though it should return 'audio/wav'.

Due to audio/wave ContentType, audio doesn't play when I access through cloud front. Instead it get downloaded.

I note that the application/javascript was deprecated two years ago now, and should be replaced by text/javascript.

For more info, see,

• https://datatracker.ietf.org/doc/rfc9239/
• https://stackoverflow.com/questions/21098865/text-javascript-vs-application-javascript
• https://stackoverflow.com/questions/876561/when-serving-javascript-files-is-it-better-to-use-the-application-javascript-or

Happy to create a PR if this change would be accepted.

For some reason lookup("map") returns 'application/json' instead of false. Shouldn't it return false since there is no extension?

Hi, can you say when do you plan to publish a new version with updated mime-db? I need mime type for WebAssembly files zeit/serve#303

Current:

mime.charset('image/svg+xml') === false

Expected:

mime.charset('image/svg+xml') === 'UFT-8'

Most recent version 1.29.0 of mime-db has an important update to markdown extensions, it would be nice to have that :)

This one's a bit tricky. The same file type is associated with two mime types depending on the shader type.

The json would look like this:

{
  "x-shader/x-fragment": [
    "shader"
  ],
  "x-shader/x-vertex": [
    "shader"
  ]
}

Source: https://developer.mozilla.org/en-US/docs/Web/WebGL/Adding_2D_content_to_a_WebGL_context

Here's a list of additional mime types. You can make requests here, and we'll mark them as added and after some discussion and references.

• .jsx - http://facebook.github.io/react/docs/jsx-in-depth.html no idea, and i think there's an extension name conflict text/jsx - http://facebook.github.io/react/docs/getting-started.html
• .litcoffee
• .ejs
• .mustache

places to look for more:

• https://github.com/showcases/programming-languages
• https://github.com/showcases/css-preprocessors

After updating packages my express app, with errorhandler, was taking about 10 minutes to start in debug mode in the Webstorm IDE. I downgraded to express 4.8.8 and errorhandler 1.1.1 and it went back to 8 seconds or so. Seems to be v2 of mime-types that causes the problem.

Related to broofa/mime#162

The v2 unit test I have in node-uuid turned up some mappings that seem "questionable" in mime-types. I believe these are a result of the more nuanced approach to extension resolution I have in v2 that prefers "standard" types over vendor (or in the "x-" cases, experimental) types.

Again, this isn't breaking anything for me, but may be worth addressing.

AssertionError: Type inconsistencies: [
  "mime-types[exe] = application/x-msdos-program, node-uuid[exe] = application/octet-stream",
  "mime-types[dll] = application/x-msdownload, node-uuid[dll] = application/octet-stream",
  "mime-types[deb] = application/x-debian-package, node-uuid[deb] = application/octet-stream",
  "mime-types[dmg] = application/x-apple-diskimage, node-uuid[dmg] = application/octet-stream",
  "mime-types[iso] = application/x-iso9660-image, node-uuid[iso] = application/octet-stream",
  "mime-types[msi] = application/x-msdownload, node-uuid[msi] = application/octet-stream",
  "mime-types[wav] = audio/wave, node-uuid[wav] = audio/wav"

So I think it would be easier and just plain more modular if this was just a repo of the IANA types themselves. I would like to propose I do the following things to (i.m.o.) bring the interface of this library into a better state:

1. I think .contentType method should only return the mime type and no charset. It could accept a second argument that is a plan object of parameters that mime-typer can format with the type (ex: mime.contentType('file.json', {charset: 'utf-8'})). This moves the charset choice to the user, and also simplifies using this library when sending KOI8-R, SHIFT_JIS, etc. This would be useful for programs writing content (they know what charset they are writing in; this lib does not).
2. I think the .charset method should not be a list of rules, but actually provide the charset for the given mime type that is registered with the IANA. This would be useful for programs reading content (they'll want to know how to decode bytes if the charset parameter is not specified).
3. We should go even further and just revive https://github.com/expressjs/set-type and make that the library where you would ask for a mime type that has some kind of defacto of compatibility charset attached rather than here. It also keeps them in their own place. File-serving libraries that don't want to figure out the charset of the file they are serving can then use set-type directly and leave it as that. This would probably override number 3 to just removing that method.

Thoughts?

In cases where the input is wrong or the result can not be provided, the current API returns false. Therefore the type signature returns this mix of string and boolean.
https://github.com/jshttp/mime-types/blob/master/index.js#L143

The more consistent and expected behaviour would be to consider "nullable types" (see http://www.typescriptlang.org/docs/handbook/advanced-types.html) and return either undefined or null with the resulting string being optional. In case the input is wrong or missing (the user makes a mistake) one could also consider to throw an error to fail early.

Is there a specific reason the API is designed as it is? Is it possible to bump major version and fix the signature regarding the amount of users?

I feel as though mime.extension should return the last added definition for the type.

Thoughts?

This relates to: koajs/koa#617.

As an extension can correspond to multiple mime-types, wouldn't it be correct to return an array of all matches and let libraries handle that?

Perhaps a .lookupAll() which strictly returns an array to avoid breaking existing code or over-complicating something which not everyone will want to make use of.

That mimetype is sent by the user, I shouldn't trust it. but I use jshttp/mime-types to not find the actual mimetype.

How should I get the true type of it?
I will change “1439542085133.txt” to "1439542085133.png"

console.log(mime.lookup('/uploads/images/1439542085133.png'));

result :
image/png

I'd love to use this package in the browser, but currently it uses Node-style CommonJS and also requires the path module for path.extname(). Would it be possible to support ESM through package.json fields, and remove the path dependency?

If you change the extension of a png file to jpg, mime.lookup will show the mime type as image/jpeg.

I believe the mime type should still be image/png.

const mimeLookup = require('mime').lookup
console.log(mimeLookup('octocat.jpg'))

Will output image/jpeg

If you use a tool like exiftool it will show the mime type to be image/png

I have the binary contents of a jpg image stored in a cache.

cache.set('logo', fs.readFileSync("./static/mylogo.jpg"));

Instead of having a separate cache for mimetypes or storing both mimetype and contents in the cache, would it be possible to determine mimetype from the cached data without knowing the path?

Example:

mime.readMime(cache.get('logo')); # Returns "image/jpg"

please tell me, when will be the new package released mime-types?
@dougwilson
https://github.com/jshttp/mime-db/releases/tag/v1.45.0

I feel like it would be useful to be able to look up the base type for suffixes that correspond to one, like:

+json => application/json
+xml => text/xml
+zip => application/zip

See: 1da5f79#diff-6d186b954a58d5bb740f73d84fe39073R38

Backwards compatibility will be included, for now.

Passing "application/json" to the mime.lookup returns false. I am assuming this is a bug and that passing a valid mime-type to mime.lookup should return that same mime-type. Also, the README says this behaves similarly to the mime module which handles this type the way I would expect. Examples below.

Using mime-types

12:33 $ node
> const mime = require('mime-types')
> mime.lookup('application/json')
false
> mime.lookup('json')
'application/json'
>

Using mime

12:38 $ node
> const mime = require('mime')
> mime.lookup('application/json')
'application/json'
> mime.lookup('json')
'application/json'
>

If this is the intended behavior, then it should probably be mentioned as a difference between this and the mime package (along with the other differences called out) in the README.

Happy to help out with a PR if this is indeed a bug and not the intended behavior

So I currently am doing the following to work out if a file is an image or not.

var extension = mime.extension(req.file.mimetype);
if(extension == "png" || extension == "gif" || extension == "jpeg" || extension == "jpg")
          {
            res.status(200).error({code:500, message: "Error with file type"});
          }

However the issue is that unless I put every file extension that is an image which lets be real, there is a lot of different formats I could miss one, it would be great to see a way that we can give the file.mimetype and it return things like: image, audio, executable, html, other.

Not sure if anyone else things this could be good.

Side topic: We noticed that mpegs end up getting mpga instead of .mp3

because why not

I added the path dependency back into the mime-types/package.json and that fixed the problem. I see that this path dependency was been a discussion topic in the past. Was the dependency added back in recent versions? I'm using [email protected]

Ionic:

   Ionic CLI                     : 5.4.13 (/usr/local/lib/node_modules/ionic)
   Ionic Framework               : @ionic/angular 4.11.7
   @angular-devkit/build-angular : 0.803.21
   @angular-devkit/schematics    : 8.1.3
   @angular/cli                  : 8.1.3
   @ionic/angular-toolkit        : 2.1.1

Cordova:

   Cordova CLI       : 9.0.0 ([email protected])
   Cordova Platforms : android 7.1.4, ios 5.1.1
   Cordova Plugins   : cordova-plugin-ionic-keyboard 2.2.0, cordova-plugin-ionic-webview 4.1.3, (and 16 other plugins)

Utility:

   cordova-res : 0.8.1
   native-run  : 0.3.0

System:

   ios-deploy : 2.0.0
   ios-sim    : 8.0.2
   NodeJS     : v10.18.0 (/usr/local/Cellar/node@10/10.18.0/bin/node)
   npm        : 6.13.4
   OS         : macOS Mojave
   Xcode      : Xcode 11.2.1 Build version 11B500

Issue

ErrorLog
(1) TypeError: extname is not a function
(2) Module "path" has been externalized for browser compatibility. Cannot access "path.${key}" in client code. See https://vitejs.dev/guide/troubleshooting.html#module-externalized-for-browser-compatibility for more details.

• When i call lookup function in Vite ^5.2.0, extname undefined error occured!

// my project environment

"@vitejs/plugin-react": "^4.2.1",
"vite": "^5.2.0",
"mime-types": "^2.1.35",

• Because Module "path" is incompatible.

How to Resolve

you can resolve this issue the following tip :)

(1) Install path-browserify. (link)

npm i path-browserify

(2) add path resolve option in vite.config.ts

import { defineConfig } from 'vite';
import react from '@vitejs/plugin-react';

// https://vitejs.dev/config/
export default defineConfig({
  plugins: [react()],
  resolve: {
    alias: [
      { find: '@', replacement: '/src' },
      { find: 'path', replacement: 'path-browserify' }, // this!!
    ],
  },
});

does that play into this library?

form, urlencoded, and form-data are some aliases. ¯\_(ツ)_/¯

[See #42 for long-ago discussion of this idea.]

As noted in that old PR, I created the mime-score module to encapsulate the logic used by mime to resolve extension conflicts in mime types. I think it would be helpful to users of mime and mime-types if both libs used the same logic.

I'll put up a PR for that (again), but the main issue with that previous PR was that mime-score didn't support [email protected]. I suspect that's no longer a concern? It'd be nice to not have to worry about that, and to be able to develop using reasonably modern language features. See #115 for further discussion there.

[Edit to add: The current support matrix is maybe even more relevent than I thought. 'Just realized that I ported mime-score to typescript last year, and it's currently built for ESNext. So, it works on node@14 but breaks on node@12.]

Not sure if you consider this an edge case, but I just tried to do this:

mime.lookup('application/x-shockwave-flash')
// return false, because x-shockwave-flash match nothing

I could be using mime.extension instead but it doesn't try to correct any input, and I was testing mime type obtained from parsing opengraph meta, ref: http://ogp.me/#structured, so I would like to correct them if possible, but I understand that may not be what mime.lookup designed to do.

if a suffix is unknown, should we lookup the extension without the suffix?

https://github.com/dherman/module-tag/blob/master/explainer.md#how-do-we-get-there-from-here

The current CI test matrix goes all the way back to [email protected]. This seems "excessive".
Over at the uuid project, we limit our test matrix to "node LTS plus one previous version". E.g. with node LTS now at v18, I expect we'll to drop support for pre-v16 versions with our next major release.

This has worked well for years, and has not caused any issues with our users. Users that want legacy platform support just pin their dependency to a prior version of uuid.

I'd like to propose mime-types do the same. This will make contributing code simpler.

maybe you guys wanna review, but there are no breaking changes in terms of tests themselves.

do we want to revive set-type? i think that's the only real question left before releasing

@dougwilson (and whoever else might be relevant here)

Hi there, I'm trying to migrate the project of my company where I work, from cra to Vite. Here's where I'm stuck:

I've checked out similar issues(all those issues have been marked as closed without any resolution) with other packages and all I got was a workaround of:
vitejs/vite#1973 (comment)
define: { 'process.env': {}, // to workaround the process.env error but not a permanent fix },
but it doesn't work in the production build, now it gives an error as the process is undefined!
I didn't face any such issues with other packages I'm using in the project.

Any help would be highly appreciated.

Please remove the path dependency from the library. It's a node function and thus not available in browsers by default.

Current builds of Angular 6 won't work because path cannot be resolved.
Also examples on Stackblitz fail, see i.e.: https://stackblitz.com/edit/angular-6-mime-types

I tried installing the path package from npm (which is super outdated) but this also fails because path internally depends on process which is also not available.

Here's the actual implementation: https://github.com/nodejs/node/blob/master/lib/path.js#L836
We could either migrate this into the project or take a much simpler approach using a very basic regex or split algo.
Here's some very good information on it: https://stackoverflow.com/questions/190852/how-can-i-get-file-extensions-with-javascript/1203361#1203361

I'd also happily provide a PR if help is wanted.

Thanks!

Looks like mp3 only gets validated on audio/mpeg. So if audio/mp3 is returned (don't say that can't be happening - multer does this.), you only get 'false'.

Hey team, I forked this project and added a few features. Wondering how you felt about the features and if I should spend some time preparing a few PRs to merge them.

• Ported to TypeScript
• Supporting browsers (path is extracted)
  • Can use via bundler
  • Can use directly via ESM (imports include .js extensions)
• Using the Node16 exports property for differential loading in Node

How do you feel about these changes, happy to raise several smaller PRs to incorporate each but don't want to drop a big PR with all these changes in one go and I know things (like TypeScript) are not to taste for some developers.

For reference: https://github.com/alshdavid/mime-types/tree/main

Seems like the current master branch have some broken tests when running Node@8 and Node@9. @UlisesGascon notice that with the PR: #121.

Similar error in both cases: https://github.com/jshttp/mime-types/actions/runs/8278038868/job/22655381584#step:10:15, here is an screenshot in case that you can't access to the logs:

It seems to be the same issue we had in http-errors

You mention clearly that requests for new mime types should be made to mime-db. This is a longterm solution for not supporting a mime-type, but what should we do in the shortterm? How can we hook into mime-types to shim in support for a mime type?