Add 'transform' config to match-exports rule

[scottnonnenberg]

Documentation included! :0)

[coveralls]

Coverage remained the same at 100.0% when pulling 2d4e71d on scottnonnenberg:add-export-transforms into 721ea9d on selaux:master.

[selaux]

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.

[scottnonnenberg]

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: match-regex. I got that all working to my needs, then discovered the match-exports rule and realized that I couldn't go any further without code changes.

[kav]

+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 export FooBar that's a pretty straightforward and common use case AFAIK. Given he has covered the standard naming conventions it seems to be flexible enough. Are there more standard naming conventions you'd expect to cover?

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.

[selaux]

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 LinkComponent being allowed in ./components/Link, but I'd rather not cover these than making the plugin unusable for you guys. So now this is about getting the PR ready to merge 🍻

[selaux]

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.

[selaux]

This can probably always be (transformed) since the user clearly sees both values and can determine whether they are transformed or not.

[selaux]

With above this can always be transformed === expectedExport

[selaux]

These should be at the top of the file (I probably should update the projects linting rules 😉 )

[selaux]

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).

[scottnonnenberg]

That should address all your feedback!

[coveralls]

Coverage remained the same at 100.0% when pulling 08bcdbd on scottnonnenberg:add-export-transforms into 721ea9d on selaux:master.

[scottnonnenberg]

Failures on platforms below Node 4.x are due to the * version specified for eslint: http://eslint.org/blog/2016/07/eslint-v3.0.0-released

[selaux]

Thanks for the rework 👍. I will adress the eslint issue on master.