-
-
Notifications
You must be signed in to change notification settings - Fork 343
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
Extending file-type #340
Comments
Interesting idea @mooyoul. The way I read it, you propose 2 things:
Although modularity is a beautiful thing, it requires additional maintenance. Not necessary for 3rd party implementation (you could argue that those would save work), but at least splitting the engine with the core. Although the intend of your example is clear to me, note that you should not read but peek to allow the next matcher to read from position 0. (I will be very busy coming weeks, please forgive me not being responsive these days.) |
We would definitely like to make it possible to provide your own matchers. There are some complications though. For example, sometimes detections are order-dependent. How should that be handled? I don't think modularizing is a good idea for I like this version the most: // or provide factroy like axios does
const fileType = FileType.create({ matchers: [webpMatcher] }); |
Dear maintainers.
First, I really appreciate that file-type has been keep maintaining. Thank you for your efforts & contributions.
Background
Recently, file-type was refactored to utilize @Borewit's awesome strtok3 packages.
With this changes, we can navigate binary stream easily & effectively.
Now, file-type uses only one Tokenizer interface regardless of source. All public methods creates Tokenizer internally and pass created tokenizer to file-type matcher.
Beside these refactors, developers cannot easily extend file-type.
If someone needs to add new file type support, There are only two choices:
Fork file-type package and customize
Pros: It does not occur additional i/o if chunk was cached internally
Cons: Less maintainability
Run custom file-type matchers if file-type returns
undefined
.Pros: More maintainability
Cons: It occurs additional I/O
As you can see, There are no effective way to extend file-type.
Idea
Expose Matcher interface
So, It would be nice if we support additional matchers.
Let's suppose there is a matcher like this:
Then, Provide custom matchers like these ways:
Future
With this idea, Developers can easily extend file-type.
From file-type's perspective, file-type can have multiple 3rd-party type matchers which can be released to npm independently, or managed via Github organization/Scoped packages (e.g.
@file-type/core
forbuilt-it matchers,
@file-type/image
for image file type matchers)Also it can be used solving unsupported features like #264 (comment).
For example, Developers can write custom TSV/CSV type matchers and publish to npm even if file-type does not provide built-in TSV/CSV file type matchers.
The text was updated successfully, but these errors were encountered: