Closed diagramatics closed 8 years ago
Thanks for the PR. Can you show me an example of the type of utilization you're describing? I don't think I quite understand the use-case.
I'm trying to get the awesome HerringtonDarkholme/gulp-progeny package to use this package instead of reinventing the wheel with some new features lacking. One of the tests include having a custom filetype and configuration so I'm getting this package to be compatible with that feature.
For a more real life scenario, take this example. The package doesn't have support for ES6 import modules yet, but if somebody wants to bake their own implementation they will be able to do so by just filling in all the options that Progeny supports and leaving the rest as null
. The latter is impossible right now because it'll throw errors on the missing configs since the default config is undefined
.
Ok, I see what you're saying now. Users can pass a custom config, but if they don't define each key and are not using a pre-defined extension, then it throws somewhere in https://github.com/es128/progeny/blob/master/src/index.coffee#L159-L167.
Makes sense. Thanks!
Also, in case you're interested, reinventing the wheel over there was apparently a deliberate choice: https://github.com/HerringtonDarkholme/gulp-progeny/issues/3#issuecomment-55207332
Fortunately I'm welcomed to make a PR to use this package instead 😁 https://github.com/HerringtonDarkholme/gulp-progeny/issues/17
I'm pretty sure this would benefit for custom implementations. Currently if you use a custom extension name for non-supported file types it'll throw a bunch of errors because you have to be super specific and fill in all the options.