Decorators cause check-param-names to fail

[Zamiell]

Expected behavior

/**
 * This is the description for my cool function.
 *
 * @param arg1 This is the number for my cool function.
 */
@MyDecorator
function foo(arg1: number) {}

This function should result in no errors.

Actual behavior

@param "arg1" does not match an existing function parameter.

Removing the decorator fixes the problem.

ESLint Config

"jsdoc/check-param-names": "warn"

[brettz9]

What version are you using? I am not getting an error for this at least with master.

[Zamiell]

I am using 39.3.6.

This is the specific function that I have, can you try to see if this one errors?

  /**
   * Helper function to register a custom pickup with the IsaacScript standard library. Use this
   * feature for custom pickups that are intended to be picked up by the player, like bombs and
   * keys.
   *
   * When IsaacScript detects that a player should be collecting the custom pickup, then the pickup
   * will be immediately removed, and an effect showing the pickup's respective `Collect` animation
   * will be spawned. (This emulates how a normal vanilla pickup would work.) After that, the
   * provided `collectFunc` will be fired. In this function, you will probably want to play a sound
   * corresponding to what kind of pickup it is (e.g. `SoundEffect.KEY_PICKUP_GAUNTLET`), as well as
   * do things like adding something to the player's inventory.
   *
   * Note that when you specify your custom pickup in the "entities2.xml" file, it should have a
   * type of "5" and be associated with an anm2 file that has a "Collect" animation.
   *
   * @param pickupVariantCustom The variant for the corresponding custom pickup.
   * @param subType The sub-type for the corresponding custom pickup.
   * @param collectFunc The function to run when the player collects this pickup.
   * @param collisionFunc Optional. The function to run when a player collides with the pickup.
   *                      Default is a function that always returns true, meaning that the player
   *                      will always immediately collect the pickup when they collide with it.
   *                      Specify this function if your pickup should only be able to be collected
   *                      under certain conditions.
   */
  @Exported
  public registerCustomPickup(
    pickupVariantCustom: PickupVariant,
    subType: int,
    collectFunc: (this: void, player: EntityPlayer) => void,
    collisionFunc: (this: void, player: EntityPlayer) => boolean = () => true,
  ): void {}

/**
 * A decorator function that signifies that the decorated class method should be added to the
 * `ModUpgraded` object.
 *
 * This is only meant to be used internally.
 */
export function Exported<Class extends Feature>(
  target: Class,
  propertyKey: keyof Class,
): void {
  // Since the decorator runs prior to instantiation, we only have access to get and set static
  // properties, which are located on the "constructor" table.
  const constructor = target.constructor as unknown as LuaTable<
    AnyNotNil,
    unknown
  >;
  if (!constructor.has(EXPORTED_METHOD_NAMES_KEY)) {
    constructor.set(EXPORTED_METHOD_NAMES_KEY, []);
  }

  const exportedMethodNames = constructor.get(
    EXPORTED_METHOD_NAMES_KEY,
  ) as string[];
  exportedMethodNames.push(propertyKey as string);
}

[brettz9]

For some reason, the arrow function default of registerCustomPickup's collisionFunc is being iterated (ArrowFunctionExpression) by ESLint when there is a decorator but not without the decorator. A quick look at the AST doesn't make it appear to be @typescript-eslint/parser-related, so I wonder if it could be ESLint's traversal. Needs to be explored further, as I think we will need to know why they are inconsistent in the first place.

[brettz9]

This should now be fixed on master (via b001cd3 ). npm releases may still be having issues on our end as per #903 (comment) . Closing as the issue is merged, but you can watch for the release.

[brettz9]

I might just mention that although I didn't determine precisely why the version with the decorator behaved differently, the issue in this case at least was that we shouldn't have been checking for JSDoc comments past an assignment pattern (the default expression needn't look further than the assignment to determine if a comment exists, e.g., the main function comment should not be considered as applicable to the default function value).

[Zamiell]

Awesome, thank you brett!