I agree, it's much cleaner with parameter properties.

I've always used them as well. What are y'all's thoughts about the argument for introducing the rule in the first place?

Parameter properties can be confusing to those new to TypeScript as they are less explicit than other ways of declaring and initializing class members.

@typescript-eslint/no-parameter-properties

It sounds like the argument is that it confuses people who don't know TypeScript? A bit of a weak argument, if you ask me.

@jedmao - Some people don't like parameter properties.
I, for one, don't like them - I don't like their look or the way they allow you to have class properties defined in two places.

As with all rules, it's there to enforce a stylistic/personal preference for code - enforcing consistent code throughout a codebase.

We should probably look at re-evaluating all of our no- rules to see if we can make them work in both directions for greater flexibility.

Copying a relevant code snippet from palantir/tslint#2638 (comment): FWIW, parameter properties are quite nice when using libraries such as Inversify:

@injectable()
class Ninja implements Warrior {

    private _katana: Weapon;
    private _shuriken: ThrowableWeapon;

    public constructor(
        @inject(TYPES.Weapon) katana: Weapon,
        @inject(TYPES.ThrowableWeapon) shuriken: ThrowableWeapon
    ) {
        this._katana = katana;
        this._shuriken = shuriken;
    }

    public fight() { return this._katana.hit(); };
    public sneak() { return this._shuriken.throw(); };
}

..compared to...

@injectable()
class Ninja implements Warrior {
    public constructor(
        @inject(TYPES.Weapon)
        private readonly katana: Weapon,

        @inject(TYPES.ThrowableWeapon)
        private readonly shuriken: ThrowableWeapon,
    ) {  }

    public fight() { return this.katana.hit(); };
    public sneak() { return this.shuriken.throw(); };
}