Expose `.types` to `.json` conversion scripts via NPM
BigBlueHat opened this issue · 10 comments
These are useful in scenarios where you have a .types
file set for your collection of servers and want to share a canonical authority across various software (much of which already use the .types
format).
These scripts could possibly be extracted into their own projects, but for now it'd just be nice to have the consumable via projects like node-ecstatic
(etc).
Thanks!
🎩
/cc @jfhbrook
I'm not sure I understand the request. It sounds like what you're requesting is it's own module: a parser for .types files. This module is simply a module to export a json database.
I can elaborate on this a little. ecstatic uses mime@1 because it supports loading .types files. mime@2 does not. I think @BigBlueHat is pulling on those threads and ended up here. I can't comment on whether mime-db is the right place to add functionality for loading .types files, but maybe you have some ideas doug?
Yea, to me it sounds like the request is for someone to make a new npm module (or maybe one already exists somewhere?) that implements a parser for the .types file format.
As for mime-db it's separation is that it's singular purpose is to provide a single json file that is usable across all environments and languages. It was divided such that it would never actually expose any javascript code itself, which would of course no longer make it a json db file.
I mean, that's a /solution/ to the request, which is ultimately "someone please come up with a migration path for .types files in mime@1". <_<; I get if you don't think this is your problem though, and I'm totally ok w/ this being a separate module. I just don't want to write it is all. ;D
Gotcha. Yea, I'm not actually involved in the mime
module, so don't know why the .load
functionality was removed and what (if any) a replacement would be. That would be like someone removing a feature of Chrome and asking Microsoft what solution Windows is going to provide since Chrome runs on Windows... ?
Perhaps this whole confusion is just the issue was opened in the wrong repo? (opened in mime-db
instead of in mime
)
Yeah, understood. Thanks for talking through this with me. 👍
No problem. I was just reading through the issue was was linked to this one and I see @BigBlueHat said:
For now I'll reach out to see if the
mime
library plans to add this (even as a separate module/script) or if we would need to directly.
Which sounds right, but then if this was the reach out mentioned, I think it was just the wrong project (this is mime-db
, which is a separate library and maintainers from mime
).
Some further reading I think there is more confusion around. I see @BigBlueHat says:
The new Mime() constructor can take the JSON files created by mime-db, so it's really about (afaict) getting .types into the .json format mime (and mime-db) use.
But I'm not seeing such an API in mime
. I'm looking at the docs https://github.com/broofa/node-mime#new-mimetypemap--more-maps and the argument is accepts looks like the following format:
{
'mime/type': ['ext1', 'ext2']
}
But that's not the format of mime-db
, which is described https://github.com/jshttp/mime-db#data-structure :
{
'mime/type': {
'source': 'IANA',
'extensions': ['ext1', 'ext2']
}
}
So it doesn't seem like the format from this module (mime-db
) is at all compatible with the argument given to the new Mime
constructor of the mime
module... ?
Really sorry for the confusion I unintentionally caused here! And for missing all the follow-ups...
I posted the issue here, mainly because these scripts are pretty close to what would be needed (possibly in a new npm module) to handle the .types
=> idiosyncratic JSON format(s): https://github.com/jshttp/mime-db/tree/master/scripts
It was that existing code (more than anything) that made me think this was a shorter road to such a module--which, afaict, doesn't exist anywhere (anymore...yet?).
Regardless, I appreciate your thoughts and input and research!! Most impressive. 😄
Sorry again for the confusion!
🎩