Add case sensitivity to 'import-name' rule

[djomaa]

Rule improvement suggestion

This rule improvement is specific for my development style, but it would not affect general style.

Why

Let's say, there is a rule for file naming using dots.case and a rule to use export default only for constructors. So importing variable should be named in PascalCase. Current import-name rule would not allow this.

Suggestion

I suggest adding an option to set the preferred string case with camelCase by default.

Use case

// ./src/master.class.ts
export default class Master {}

// ./src/another.file.ts
import Master from './master.class';
class Slave extends Master {} 

[JoshuaKGoldberg]

Hi @djomaa! I'm a little confused about what the exact difference is you're proposing. Can you elaborate on the different situations for import names you're thinking of, and for each of them, what the behavior of the rule is now compared to what you'd like it to be?

[IllusionMH]

As I see - this change is aimed to adopt this rule for applications that extensively use default imports of classes (and namespace objects?) which aren't allowed ATM. And I agree with this proposal.

How about cases when app (pretty big) has both default exports of classes and factories/helpers?
@djomaa @JoshuaKGoldberg do you think it makes sense to allow third option any (or other name) - less restrictive setting that will check for both of proposed cases?

[djomaa]

@JoshuaKGoldberg Current rule implementation converts each file name to camelCase, and then compares it with the variable name. Thus, there is no way to name variables using PascalCase without changing a file name.

Some examples can be seen in the pull request related to this issue (thx @IllusionMH).
Let me know if you need more examples.

@IllusionMH It can be done. Frankly speaking, that's what I did at the very beginning. But then the changes were discarded due to some problems that have been solved later.