This is a good question and interesting topic, my bias is towards the thinking that it doesn't really matter what you styles you decide upon as long as they are enforced and consistently applied.
As such it is probably better have no style preference until there is time to configure it for your editor(s), build and CI pipelines. It is a huge waste of time if it is something you spend a lot of time manually overseeing and discussing in code reviews etc.
As such I fully agree with the other suggestions to look into tools built for ESLint or StandardJS. Prettier is a formatter only and not a linter, so can be combined with either ESLint or StandardJS.
I also wouldn't worry about these being heavy weight as the point of the editor integration (and build integration) is that you don't need to learn each and every rule by rote - rather that the rules are be checked on your behalf as you type (or save).
The idea with Airbnb (and other guides) is that you take it as a base and then customise it to your needs by overriding rules you disagree with or do not require. In practice this involves applying it to your project to see how many errors and warnings you get (it might be a lot and don't worry if this is the case as a lot will be duplicates). Then spend the time tweaking the rules to your liking. For a code base which is not linted this will take a bit of effort upfront, but the benefits far outstrip this initial investment.
Later on you may wish to look at a quality gate tool like SonarJS. This is concerned with enforcing consistent style, but also performs static analysis and catches possible bugs, code smells and even some security issues.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
This is a good question and interesting topic, my bias is towards the thinking that it doesn't really matter what you styles you decide upon as long as they are enforced and consistently applied.
As such it is probably better have no style preference until there is time to configure it for your editor(s), build and CI pipelines. It is a huge waste of time if it is something you spend a lot of time manually overseeing and discussing in code reviews etc.
As such I fully agree with the other suggestions to look into tools built for ESLint or StandardJS. Prettier is a formatter only and not a linter, so can be combined with either ESLint or StandardJS.
I also wouldn't worry about these being heavy weight as the point of the editor integration (and build integration) is that you don't need to learn each and every rule by rote - rather that the rules are be checked on your behalf as you type (or save).
The idea with Airbnb (and other guides) is that you take it as a base and then customise it to your needs by overriding rules you disagree with or do not require. In practice this involves applying it to your project to see how many errors and warnings you get (it might be a lot and don't worry if this is the case as a lot will be duplicates). Then spend the time tweaking the rules to your liking. For a code base which is not linted this will take a bit of effort upfront, but the benefits far outstrip this initial investment.
Later on you may wish to look at a quality gate tool like SonarJS. This is concerned with enforcing consistent style, but also performs static analysis and catches possible bugs, code smells and even some security issues.