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) { |
selaux
Jul 12, 2016
Owner
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.
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.
@@ -34,16 +56,18 @@ module.exports = function(context) { | |||
exportedName = getExportedName(node), | |||
isExporting = Boolean(exportedName), | |||
expectedExport = getStringToCheckAgainstExport(parsed), | |||
transformed = transform(exportedName, context), | |||
transformedText = transformed ? ' (transformed)' : '', |
selaux
Jul 12, 2016
Owner
This can probably always be (transformed)
since the user clearly sees both values and can determine whether they are transformed or not.
This can probably always be (transformed)
since the user clearly sees both values and can determine whether they are transformed or not.
everythingIsIndex = exportedName === 'index' && parsed.name === 'index', | ||
matchesExported = expectedExport === exportedName || everythingIsIndex, | ||
matchesExported = (transformed ? transformed === expectedExport : expectedExport === exportedName) || everythingIsIndex, |
selaux
Jul 12, 2016
Owner
With above this can always be transformed === expectedExport
With above this can always be transformed === expectedExport
@@ -135,3 +135,94 @@ ruleTester.run("lib/rules/match-exported", exportedRule, { | |||
} | |||
] | |||
}); | |||
|
|||
var camelCaseCommonJS = "module.exports = variableName;", |
selaux
Jul 12, 2016
•
Owner
These should be at the top of the file (I probably should update the projects linting rules 😉 )
These should be at the top of the file (I probably should update the projects linting rules
); | ||
} | ||
} | ||
}; | ||
|
||
module.exports.schema = [ |
selaux
Jul 12, 2016
Owner
Can we keep this as an array for now to be consistent with the other rules? Although I also like the object version, but then it should be there for all rules (and thus requires a major update).
Can we keep this as an array for now to be consistent with the other rules? Although I also like the object version, but then it should be there for all rules (and thus requires a major update).
That should address all your feedback! |
Failures on platforms below Node 4.x are due to the |
Thanks for the rework |
Documentation included! :0)