I agree that it's redundant, but at least the double assignment is not incorrect...

I could imagine the current behavior of this PR being somewhat helpful in some scenarios:

• When type checking, you want readonly typing
• When compiling with js: true, you want the assignment

Probably better would be for Civet to support readonly (and public etc.) in js: true mode, turning into an assignment just like an @ binding. I assume other TypeScript transpilers support this? Yes, esbuild does. Anyway, then we could detect and remove the duplicate, or rather, trigger once when there's an @ binding or has a TypeScript specifier.

Probably better would be for Civet to support readonly (and public etc.) in js: true mode, turning into an assignment just like an @ binding

Actually, it looks like we already did this, some time ago.

Here's a fun situation:

class Foo
  @(public @var)

Currently we compile this to:

class Foo {
  constructor(public _var){this.var = _var;}
}

This declares the wrong thing public. But we also don't want to omit the _. I think we need to compile to

class Foo {
  public var
  constructor(_var){this.var = _var;}
}

So I'm tempted to lift public/readonly/etc. to the type declaration, using the existing type declaration lifting. But unlike type lifting, we won't duplicate the modifiers; we'll remove them from constructor.

OK, there shouldn't be any duplicate this assignment when mixing access modifiers with @ bindings now, using the alternate compilation above.