JamieMason / eslint-plugin-prefer-arrow-functions

Auto-fix plain Functions into Arrow Functions, in all cases where conversion would result in the same behaviour
https://www.npmjs.com/package/eslint-plugin-prefer-arrow-functions
MIT License
43 stars 11 forks source link

Prevent or ignore overload functions #17

Closed grikomsn closed 4 months ago

grikomsn commented 1 year ago

Description

First and foremost, thank you for the plugin!

Don't know if this should be a bug or a feature issue, but I tried using this plugin and it seems that it also handles overload functions. Related code below:

https://github.com/strangelove-ventures/graz/blob/94eea291ac2b8ce482e06c3182bfddc92c1a557b/packages/graz/src/actions/clients/tendermint.ts#L125-L145

Or a pseudo-code example:

// example overload functions which handles merging objects with respected types
function example(): object;
function example<A extends object>(a: A): object & A;
function example<A extends object, B extends object>(a: A, b: B): object & A & B;

// this function should not be handled by the plugin
export function example(...args: object[]): any {
  // some logic here
}

When running lint fix, this function should not be converted to arrow function because it will break its intended behavior.

Suggested Solution

If it's possible to know if a function is an overload function, ignore the rule.

Help Needed

Since I am not proficient in AST related things, it'd be helpful if someone can guide on how to implement this. I'd love to contribute!

grikomsn commented 1 year ago

One solution I found for typed overload arrow functions is to extract into separate type declaration seen here: https://stackoverflow.com/a/53143568/4273667

Using previous pseudo-code above, the solution will be:

// instead of declaring separate overload fns,
// using type/interface can merge all definitions
type Example = {
  (): object;
  <A extends object>(a: A): object & A:
  <A extends object, B extends object>(a: A, b: B): object & A & B;
}

// typed variable with an additional benefit on not defining return type
export const example: Example = (...args: object[]) => {
  // some logic here
}

Guess for this issue, it could be either out of scope or wontfix-able. Regardless, would love to hear any feedback regarding this. 😄