I wonder if a discussion about naming is needed, because I'm not sure what enum-literals is.

maybe would be better if it was called no-enum-literal-comparison?

It also prevents you from using literals instead enum params

@mohsen1 - I can see a valid test for that, but there's no invalid test.

Correct me if I'm wrong - but I don't see you using the CallExpression selector, so it seems like that case isn't covered by this?

oh wow! how did I miss that? I'll work on it. Meanwhile, let's finalize the naming.

even though it doesn't technically cover the CallExpression case, I think that no-enum-literal-comparison still does a good job of explaining what the rule does.

How about prefer-enum-member or use-enum-member?

This rule looks like to handle enums as a nominal type. (related: microsoft/TypeScript#202)

Because the type system of TS is structural typing, enums are compatible with the actual types (number or string) of each enum. Then, this rule tries to disable the compatibility of structural typing about enums. (in other words, this rule tries to make enums nominal typing.)

Now, how about nominal-typed-enum or no-structural-typed-enum?

EDIT: I may be misunderstanding something. 🤔

my only problem with using nominal or structural in the rule name is that most TS users wouldn't know what those words mean.

I spend a decent chunk of time poking around typescript, and I still had to look up their meanings.

Maybe instead we could take a leaf out of flow's books and use the word opaque?
It's a more commonly used/understood word, so it would make it easier to understand the rule

opaque-enum / no-transparent-enum

I like opaque-enum!

I'm still working on this. Functions and methods with overloading and all that is complicated. I also like the name opaque-enum

Hi @mohsen1, thanks again for the PR, when do you think you will have chance to finalise this one?