react-dropzone / attr-accept Goto Github PK

View Code? Open in Web Editor NEW

109.0 7.0 28.0 1.28 MB

JavaScript implementation of the "accept" attribute for HTML5 input element

License: MIT License

JavaScript 100.00%

file-validation file

attr-accept's Introduction

attr-accept

JavaScript implementation of the "accept" attribute for HTML5 <input type="file">

See https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/file#attr-accept for more information.

Installation

npm install --save attr-accept

Usage

var accept = require('attr-accept');
accept({
    name: 'my file.png',
    type: 'image/png'
}, 'image/*') // => true

accept({
    name: 'my file.json',
    type: 'application/json'
}, 'image/*') // => false

accept({
    name: 'my file.srt',
    type: ''
}, '.srt') // => true

You can also pass multiple mime types as a comma delimited string or array.

accept({
    name: 'my file.json',
    type: 'application/json'
}, 'application/json,video/*') // => true

accept({
    name: 'my file.json',
    type: 'application/json'
}, ['application/json', 'video/*']) // => true

attr-accept's People

Contributors

Stargazers

Watchers

attr-accept's Issues

Allow passing an array of mime-types

Moved from react-dropzone/react-dropzone#243

When passing in an array of mime types, it is correctly limiting available selections for the onClick file selector (non-accepted files are greyed out), but drag and drop does not work and it throws an error in the console saying that a string should be passed. Would it be possible to enable an array of mimetypes?

Certain file types are not allowed

Per this issue in react-dropzone
It seems the check on file types has been changed in browser support as it makes those that have a filetype that includes a . to a blank string. The example here is a .stl file. This is an example file from a basic input file type tag

File(7138484) {name: "Apollo_11.stl", lastModified: 1440523936000, lastModifiedDate: Tue Aug 25 2015 10:32:16 GMT-0700 (Mountain Standard Time), webkitRelativePath: "", size: 7138484, …}
lastModified
:
1440523936000
lastModifiedDate
:
Tue Aug 25 2015 10:32:16 GMT-0700 (Mountain Standard Time) {}
name
:
"Apollo_11.stl"
size
:
7138484
type
:
"model/x.stl-binary"
webkitRelativePath
:
""
__proto__
:
File

use : var accept = require('attr-accept'); accept() accept is not a function

use : var accept = require('attr-accept');
then: accept()
result: accept is not a function

solution: import accept from 'attr-accept' ????

Accept custom extensions like html file input

In <input type='file'>, the fact that you can use the accept prop for random extensions (like accept='myext') is rather handy for all those that create and use proprietary file types.

Getting into react-dropzone, is it true that this example by @export-mike (copied below) is currently the best shot?

Pseudo code:

< ... accept="" onDrop={file => {
 if(!file.name.endsWith('.csv')) { this.setState({ rejected: true }) }
 // doSomething();
} >

Are there any plans for extending the accept prop in the same way file inputs work? When users browse files, it's nice to have them filtered by the extension(s) that'll work.

Thank you!

accept: MIME type should be case insensitive

Do you want to request a feature or report a bug?

I found a bug
I want to propose a feature

What is the current behavior?

The MIME type check with accept config is case-sensitive, but it should be case-insensitive according to SO / specs. Source: https://stackoverflow.com/a/12869287/4717408. Here is a scenario where it impacts the behavior. For an Excel file with extension .xlsm, we have the MIME types:

On Chrome Windows: application/vnd.ms-excel.sheet.macroEnabled.12 (upper-case E)
On Chrome Mac: application/vnd.ms-excel.sheet.macroenabled.12 (lower-case e)

This leads to a behavior a bit hard to understand when I develop on Windows (I have copy/pasted the official MIME type which is the first variant, so I'm not aware of the case issue) and I test later on Mac. If I'm not familiar with detailed MIME type specs like being case-sensitive or not, or different platforms providing different cases, it will take some time before I find the source cause.

If the current behavior is a bug, please provide the steps to reproduce.

Sandbox: https://codesandbox.io/s/vigilant-curran-jqxwi

provide accept: "application/vnd.ms-excel.sheet.macroEnabled.12" MIME type filter
Try on Windows: it works (you can upload .xlsm Excel files)
Try on Mac: it does NOT work. Reason: the MIME type on Mac is application/vnd.ms-excel.sheet.macroenabled.12 (lower-case e)

What is the expected behavior?

The MIME type should be case-insensitive, so providing any case in the accept config should work.

Please mention other relevant information such as the browser version, Operating System and react-dropzone version.

Chrome, latest version on Windows and Mac

The current workaround is to provide both cases in the list of accepted MIME types: https://codesandbox.io/s/agitated-night-52c6b

Issue initially created here

Btw, thanks for this great lib!

[Edit] Here is the PR: #51

对.xls文件的判断return false

https://github.com/okonet/attr-accept/blob/2847ab8c065ee41092f012c8a5b61e84263c815f/src/index.js#L21，
.xls文件的file.type为空字符串，
.xls允许的accept为application/vnd.ms-excel，
这样导致.xls文件返回false

Add Contributing.md

The document should state

the workflow,
the fact this repo uses semantic-release
the fact it uses angular commit messages

support require('attr-accept');

not big issue but could it support

const attrAccept = require('attr-accept');

instead of

const attrAccept = require('attr-accept').default;

es5 compatibility

This PR broke es5 compatibility: #47
module field now points to the original, non-transpiled source - this might be considered a breaking change

react-dropzone itself has a module field but it has another build for es:
https://github.com/react-dropzone/react-dropzone/blob/master/package.json#L11
https://github.com/react-dropzone/react-dropzone/blob/master/package.json#L5

Last fix was not published on npm

It seems like 5d4cdf8 was not published on npm due to some error on Travis:

after_success
1.36s$ travis-deploy-once "npm install -g semantic-release@13 && semantic-release"
{ HTTPError: Response code 403 (Forbidden)
    at stream.catch.then.data (/home/travis/build/react-dropzone/attr-accept/node_modules/got/index.js:341:13)
    at <anonymous>
    at process._tickCallback (internal/process/next_tick.js:189:7)
  name: 'HTTPError',
  host: 'api.travis-ci.org',
  hostname: 'api.travis-ci.org',
  method: 'POST',
  path: '/auth/github',
  protocol: 'https:',
  url: 'https://api.travis-ci.org/auth/github',
  statusCode: 403,
  statusMessage: 'Forbidden',
  headers: 
   { connection: 'close',
     server: 'nginx',
     date: 'Sat, 12 Oct 2019 05:22:35 GMT',
     'content-type': 'application/json',
     'transfer-encoding': 'chunked',
     'strict-transport-security': 'max-age=31536000',
     'x-endpoint': 'Travis::Api::App::Endpoint::Authorization',
     'x-pattern': '/github',
     'x-oauth-scopes': 'public',
     'x-accepted-oauth-scopes': 'public',
     vary: 'Accept,Accept-Encoding',
     'content-encoding': 'gzip',
     'x-rack-cache': 'invalidate, pass',
     'x-request-id': '117769e9-6c3a-414c-b2c5-f54c1bcba3a1',
     'access-control-allow-origin': '*',
     'access-control-allow-credentials': 'true',
     'access-control-expose-headers': 'Content-Type, Cache-Control, Expires, Etag, Last-Modified, X-Request-ID',
     via: '1.1 vegur' } }

Is it possible that we're missing some token or whatever token we used expired?

This change would probably also fix react-dropzone/react-dropzone#887.

Feature Request: Split into two functions: getMimeType() + validateMimeType()

I'd like to use this same lib not only for validation, but determining which type a given file is as well.

Signatures

function getMimeType(file?: File): { baseType, type } {
  ...
}

function validateMimeType(file?: File, acceptedFiles?: string | string[]): boolean {
  ...
  const { baseType, type } = getMimeType(file)
  ...
}

Sample Usage

const myFile = <a file>

if (!validateMimeType(myFile)) { throw new Error('not a valid file type') }

if (getMimeType(myFile).baseType === 'image') {
  // present preview of the image
} else {
  // present a generic file icon
}

Please deploy updated npm module

It looks like the code in the repo was updated since 2016 (in particular ES6 babel config fixed Babel 5 deprecation).

But npm module is still 1.1.0:
https://www.npmjs.com/package/attr-accept

Please deploy a new version to npm

ESM build?

Is your feature request related to a problem? Please describe.
When including attr-accept in an ESM library, Vite fails to properly convert from CJS to ESM. See soorria/solid-dropzone#3 for a real-world example.

Describe the solution you'd like
Offer an ESM build parallel to the current CJS options. I believe a larger Webpack configuration can do this relatively easily.

Describe alternatives you've considered
Forking just to produce our own ESM build.

Demo not working

The automated release is failing 🚨

🚨 The automated release from the `master` branch failed. 🚨

I recommend you give this issue a high priority, so other packages depending on you could benefit from your bug fixes and new features.

You can find below the list of errors reported by semantic-release. Each one of them has to be resolved in order to automatically publish your package. I’m sure you can resolve this 💪.

Errors are usually caused by a misconfiguration or an authentication problem. With each error reported below you will find explanation and guidance to help you to resolve it.

Once all the errors are resolved, semantic-release will release your package the next time you push a commit to the master branch. You can also manually restart the failed CI job that runs semantic-release.

If you are not sure how to resolve this, here is some links that can help you:

If those don’t help, or if this issue is reporting something you think isn’t right, you can always ask the humans behind semantic-release.

Invalid npm token.

The npm token configured in the NPM_TOKEN environment variable must be a valid token allowing to publish to the registry https://registry.npmjs.org/.

If you are using Two-Factor Authentication, make configure the auth-only level is supported. semantic-release cannot publish with the default auth-and-writes level.

Please make sure to set the NPM_TOKEN environment variable in your CI with the exact value of the npm token.

Good luck with your project ✨

Your semantic-release bot 📦🚀