Closed manuelbieh closed 6 years ago
:question:
Merge would be really nice!
Sorry folks, I've been unusually busy with both work and life for a sustained period of time now. I keep meaning to get to these PRs (and other projects), but don't find myself with the time + energy too often.
One thing I've done with another project is to invite one or two other people to be collaborators in the project and help maintain it. Anyone here interested in that?
I'd just ask that you be mindful of keeping this project focused, and not let it get too complex. E.g. I'm not 100% sure it's a good idea to accept all of the currently open PRs, but I haven't looked into them fully or thought deeply about it.
Apologies again for the delay, and thank you for understanding. =)
Have a look at this article! http://felixge.de/2013/03/11/the-pull-request-hack.html
By the way: my PR is fully backwards compatible. Breaks nothing, adds new features, covered with tests. So it would most certainly not cause any problems to merge my PR ;)
I love that article and indeed followed it for another project:
https://github.com/aseemk/json5/graphs/contributors
That project was very well defined and constrained, though ("strict subset of JavaScript").
With requireDir
, I fear that if every currently open PR was merged, this project would lose its simplicity and become a minefield of options. I totally realize I might be being overly conservative, though.
Anyway, that's my current thought process for why I'd prefer one or two maintainers that stay mindful of the big picture. =) Thanks for the feedback!
E.g. here, I already kind of regret adding the camelcase
option previously, if that wasn't good enough for your use case. And I'm reluctant to add an option that has multiple different types of camelcasing, and requires the developer to think about "cleaning up", etc.
(Not quite the same, but reminds me of this great article: http://robotlolita.me/2016/01/09/no-i-dont-want-to-configure-your-app.html )
Again, I haven't thought deeply about all of this. And no offense intended. Thanks again!
Hi there,
I'm sorry I haven't been timely in responding to these issues and PRs.
If you're interested in taking over the maintainer role for this project, please let me know.
More details: https://github.com/aseemk/requireDir/pull/31#issuecomment-255744987
Cheers, Aseem
Hi - new maintainer here. I'd like to make a more generic map
function to accomplish things like this, with a syntax you can use like: mapName: (f) => camelize(f), map: (o) => o.default || o
.
I'm going to close this PR in favor of doing that, it should be up in the next npm release.
Hey,
I needed a way to differ between modules from different folders (in my case controllers and models) which made me add an
append
option:=>
{ aModel: 'a', bModel: 'b', aController: 'a', bController: 'b' }
I also added a new option
transform
since I wanted my modules to be compliant with my UpperCamelCase convention, so I addedtransform: 'ucfirst'
as new option which will returnLogin
if the file is named 'login.js'And because it's nothing else than another transformation-style I also allowed
camelcase
to be used as value for the transform option:{ transform: ['camelcase', 'ucfirst'] }
(or simply{ transform: 'camelcase ucfirst' }
since it is a simple indexOf lookup). I did not remove the oldcamelcase
option to be backwards compatible.To avoid having confusing module names with the same name in the returned object, I also added another option
cleanup
which removes modules which were renamed using atransform
,append
orprepend
.I added tests for every new option to make sure nothing breaks. All new options are of course optional and everything should be completely backwards compatible so it can be merged safely :)