no support for TaggedTemplateLiteral?

Would probably good to support them for things like graphql tagged strings:

readonly query = graphql`
  query {
    # ...
  }
`;

Very good point! I've added support, with the same bailout on if they've got any expressions since we'd have to scope-check them which is probably overkill (unless I've missed the magic method that checks exactly that?).

I've also not had the fixer bother trying to make them look nicer by having them multi-line, as that feels like more overkill as we'd have to try to calculate indentation.

Let me know what you think :)

stylistically, do you think more people enforce spaces inside function body?

get foo() {return 1}
// or
get foo() { return 1; }

I think more people do the latter, so it might be good to do it to save the majority having to edit it afterward?

I use prettier in everything, so it's no skin off my nose. I'm happy with whatever you want to do.

I don't know how interactions between rules work, but how would this interact with the block-spacing eslint rule? Same question about the semi rule for the return statement.

Sorry @bradzacher, I just wasn't clear from your comment if these other rules would fix this if they are set based on your remark about "having to edit it afterward".

The docs explain this better than I can:

https://eslint.org/docs/developer-guide/working-with-rules#applying-fixes

After applying fixes, ESLint will run all of the enabled rules again on the fixed code, potentially applying more fixes. This process will repeat up to 10 times, or until no more fixable problems are found. Afterwards, any remaining problems will be reported as usual.

Best practices for fixes:
\4. Since all rules are run again after the initial round of fixes is applied, it's not necessary for a rule to check whether the code style of a fix will cause errors to be reported by another rule.

One exception to this is fixers applied via an IDE - fixing a single error via the IDE will run the fixer exactly once.

Which is why when applying larger fixes like this, I still like to try and go with what I believe to be the "most common" styling, so there's less chance of the fix causing a lint error, and so people are less likely to want to fix it up manually afterward.

One exception to this is fixers applied via an IDE - fixing a single error via the IDE will run the fixer exactly once.

That's a good point - I'm not particularly fussed, and do prefer the nicer output in the tests anyway, so +1

Considering you're pretty much replacing the entire node, I would just simplify this and actually replace the entire node:

let text = printNodeModifiers(node, 'readonly');
const name = sourceCode.getText(node.key);
if (node.computed) {
  text += `[${name}]`;
} else {
  text += name;
}
text += ` = ${sourceCode.getText(argument)};`;
return fixer.replace(node, text);

Happy to do so, but note that replacing the entire node means that any comments would be lost:

readonly /* public */ p1 = 'hello world'

tbf, you're nuking the majority of the comments anyways 😄

/* */ public /* */ static /* */ readonly /* */ p1 /* */ = /* */ 'hello world' /* */;

I think your current code only keeps the outer two comments.
Replacing the node would also only keep the outer two comments.

If someone comes later on to complain about missing comments, we can reassess the fixer - I'm not fussed about killing comments in really weird places.

I'm not fussed about killing comments in really weird places.

That's my feelings too :)

same comment as the above fixer - might be better to just replace the entire node.