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
Add 'transform' config to match-exports rule #9
Conversation
Documentation included! :0)
Thanks for the PR. I'm not sure though if this is actually a common use case. Additionally having a predefined set of these matching rules looks weird to me (i.e. why do we only support exacty these cases). So I would rather wait to merge until more people chive in. |
Hm. I can certainly say that I can't use it without the changes - I'm not willing to introduce case-sensitivity into my project filenames, having been bitten going from dev to production in the past. I did take some time to consider configurability. You're right, that set of three is limited, and it is a subset of what people might want. Of course, those are the first three options I can think of when transforming an identifier, so there's that. Could always introduce the ability to provide a custom transform, but that would only be available to people providing their configuration in javascript. To me, this change made sense given the configurability of that primary rule in this plugin: |
+1, I don't use camel case filenames so the default configuration of the match-exported rule is useless without @scottnonnenberg's changes. The use case is foo-bar.js should In general in fact I'd love a rule that offers those options to enforce these filename patterns over an arbitrary regex. I don't need infinite flexibility regex provides here. I need consistency with common best practices. Perhaps you'd disagree but I'd argue it's ok for linter rules to proscribe a set of options based on common coding patterns. |
You're right. It might be a common use case for existing code bases (especially for projects developed on OS X and Windows and deployed to Linux). The issue I see with flexibility is with rather fringe use-cases like |
@@ -24,6 +27,25 @@ function getStringToCheckAgainstExport(parsed) { | |||
} | |||
} | |||
|
|||
function transform(exportedName, context) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What about:
/// ...
var transforms = {
kebab: kebabCase,
snake: snakeCase,
camel: camelCase
};
// ...
function transform(exportedName, transformName) {
var transform = transforms[transformName];
return transform ? transform(exportedName) : exportedName;
}
This way the exported name can always be passed to this function regardless of wether a transform option is actually passed.
That should address all your feedback! |
Failures on platforms below Node 4.x are due to the |
Thanks for the rework 👍. I will adress the eslint issue on master. |
Documentation included! :0)