jshttp / mime-types Goto Github PK
View Code? Open in Web Editor NEWThe ultimate javascript content-type utility.
License: MIT License
The ultimate javascript content-type utility.
License: MIT License
Most recent version 1.29.0
of mime-db
has an important update to markdown extensions, it would be nice to have that :)
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'.
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.
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?
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
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"
For some reason lookup("map")
returns 'application/json' instead of false. Shouldn't it return false since there is no extension?
I note that the application/javascript was deprecated two years ago now, and should be replaced by text/javascript.
For more info, see,
Happy to create a PR if this change would be accepted.
@dougwilson (and whoever else might be relevant here)
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
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
please tell me, when will be the new package released mime-types?
@dougwilson
https://github.com/jshttp/mime-db/releases/tag/v1.45.0
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.
// my project environment
"@vitejs/plugin-react": "^4.2.1",
"vite": "^5.2.0",
"mime-types": "^2.1.35",
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!!
],
},
});
I feel as though mime.extension should return the last added definition for the type.
Thoughts?
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.
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"
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
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
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
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
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
See: 1da5f79#diff-6d186b954a58d5bb740f73d84fe39073R38
Backwards compatibility will be included, for now.
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.
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.
does that play into this library?
form
, urlencoded
, and form-data
are some aliases. ¯\_(ツ)_/¯
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!
[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
.]
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
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
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?
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.
path
is extracted)
.js
extensions)exports
property for differential loading in NodeHow 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
because why not
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.
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:
.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)..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).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?
Current:
mime.charset('image/svg+xml') === false
Expected:
mime.charset('image/svg+xml') === 'UFT-8'
This library adds some useful functionality to the mime-db database, but it also "hides" certain information. Why not expose source
and compressible
? Or just expose the internal db
?
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.
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
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
- text/jsx
- http://facebook.github.io/react/docs/getting-started.html.litcoffee
.ejs
.mustache
places to look for more:
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.