// This appears 2 times in our codebase
import classNames from 'classnames';
// This appears 5 times in our codebase
import classnames from 'classnames';
Let's standardize on this one way or the other.
Go with classnames for majority rule.
Based on the package name, if we were to consider dashes (-) as equivalent of separate words as camel-case breaks, it should really only be classNames if the package were named class-names. I personally _prefer_ classNames, but if this camel-casing convention is one we'd want to follow, classnames would be the correct option.
+1 on classNames then.
I don't care either way here, as long as we are consistent. How difficult would it be to make this into a lint rule? Is this necessary?
+1 on
classNamesthen.
To be clear, I'm suggesting classnames as the correct option 馃槢
How difficult would it be to make this into a lint rule?
Not terribly difficult. Would be a visitor on ImportDeclaration asserting the name of ImportDefaultSpecifier's local identifier.
http://eslint.org/docs/developer-guide/working-with-rules
http://astexplorer.net/#/gist/9d48f86dd8ee2796126a46790a6a8488/957c7d8ddcef1d213ad8b62f1074dee3eb6cb050
Is this necessary?
Hmm, I'd not oppose it, but dunno it's worth the effort. I could see more value in something generic like linting camel-case import names of external resources' default exports.
https://make.wordpress.org/core/handbook/best-practices/coding-standards/javascript/#naming-conventions
Variable and function names should be full words, using camel case with a lowercase first letter. This is an area where this standard differs from the WordPress PHP coding standards.
In this case you could argue that classnames is a full word meaning "the npm package called classnames".
Actually, with a combination of ESLint AST selectors and the no-restricted-syntax rule, this might be fairly easy to implement.