no-nil doesn't seem to understand default switch case about eslint-plugin-fp HOT 10 OPEN

I found another construct to support: try/catch.

from eslint-plugin-fp.

I get this error (and fp/no-nil too) for class constructors also, .e.g:

  constructor(props) {  // <- fp/no-nil error
    super(props);
    this.state = { display: 'static' }; // <- fp/no-mutation error
  }

from eslint-plugin-fp.

Ah you're right. It also doesn't support if/else statements like

function foo() {
   if (foo) {
     return 1;
   } else {
     return 2;
   }
   // Error: does not end with return
}

I was pretty sure that there was a core ESLint rule that required a return statement in every possible path, but I can't find it, so I might be mistaken. I was thinking that I could stop checking the missing return statements, leave them to that rule and just check the return statements. But if I can't find it, never mind.

I can add support for the switch and if/else cases. Do you have other constructs in mind? I don't use loops anymore but there might be some constructs where you always return in the loop and never go past it. Would love some help on that. Not with the implementation (though if someone wants to have a go at it, let me know!), but with trying to find the cases to support.

Note to myself, this rule also needs to report return void value, which I just learned also returns undefined.

from eslint-plugin-fp.

Yeah, I really want to keep the "no-nil" rule, but I use switch statements extensively with Redux. :/

from eslint-plugin-fp.

I'm experiencing this as well :(

from eslint-plugin-fp.

Since this is a fp plugin, I wouldn't worry about loops too much :)
So yeah I'd focus on switch and if/else as well.

from eslint-plugin-fp.

Well, this plugin aims to make JS into a really FP-like language when all the rules are turned on (would be curious how you all use it by the way), but that's not always the case.

I use it at my workplace, where we use it partially, as some rules are nice to have even in non-full-FP codebase (no-arguments, no-class, no-delete, no-events, no-get-set, no-loops, no-proxy, no-this...). But we still have files with mutation for instance. Therefore, I can't make the assumptions in the rules (as I may previously have thought) that the other rules will cover the other cases.

I have no problem with supporting if/else and switch, and wait for someone to ask me to support loops, but that would not be ideal :)

from eslint-plugin-fp.

@vyorkin See #22

from eslint-plugin-fp.

Is there any workaround for this issue?

from eslint-plugin-fp.

So, I've been taking a look at the plugin source code and think I have a few solutions to offer switch statement compatibility and would love to contribute but I'd like to discuss desired utility.

I believe the reportFunctions use of endsWithReturnStatement is too limiting and needs to be changed in some way to offer switch/if-else utility.

We could do away with the endsWithReturnStatement check and replace with a check that just ensures that the block statement does contains a return statement. An extremely loose implementation but I do believes it addresses the intent of ensuring the function does return something and ReturnStatement of create already checks to ensure that the return value is not null. On a side point is there a reason the ReturnStatement of create only checks for null and not undefined as well?

As for specific switch statement implementation I can think of two possible scenarios, either require just the default case to contain a return statement or require all cases to contain a return statement. This is certainly a much more strict implementation but I do feel it is more in-line with how that implementation is used in functional programming even if it does pigeon-hole switch statements to just return value control flow.

Personally, I side with the first implementation as I'm not really a fan of limiting switch statement implementation for anyone who uses the rule. A third option would to be create an entirely new rule that addresses return values but I that's probably overkill.

from eslint-plugin-fp.