76 open 947 closed 100k stars 20k forks
overall, the main dude
ljhard has the dual role of community building and code-fixing, and explains the rationale, thus moving the debate from personal preferences to technical know-how to practical implementation (eslint configs)
at the bottom of the README, there is:
We encourage you to fork this guide and change the rules to fit your team’s style guide. Below, you may list some amendments to the style guide. This allows you to periodically update your style guide without having to deal with merge conflicts.
that means they are keenly aware that there are technical implications (as in, tools are there), and perhaps their success could be by acknowledging those and creating a sort of network/cooperation of the willing
i guess this is an example in which the discursive strategies on github are first and foremost established by the organization in such a way that prevents too much debate (commercial weight, acknowledgement of alternatives)
again, very much about whether or not the linter rules would complain src
and about tools as solutions src
ljhard about his opinion
assumption that ESLint and Airbnb are tightly coupled, so that if it’s not in Airbnb it’s not possible (i.e. guide is exhaustive) src
kinda street-level bureaucracy, what
ljharb is doing
other technical justification src
what’s up with not closing questions?
First of all, great job on this guide, I agree with it almost 100%. All of this should really be common knowledge, but I sure as hell didn’t know most of these things when I started, so kudos for writing it all down.
the above dude is refering specifically to AirBnB (as the org)
which also makes sense: the guide itself is not up to debate, only its implementation
but then here he says that the guide is more important than the linter (#1 guide, which is solved for airbnb, #2 linter)
polling all contributors -> by opening the issue, they control the narrative, and also ruling out aeshtetic preferences, which commenters follow
ljhard works for
If avoiding it was an official stance, or if there was a real technical hurdle to using it, I would drop this. But I don’t like the idea of just arbitrarily banning something without technical merit.
[https://github.com/jsx-eslint/eslint-plugin-jsx-a11y/issues/527] following the town hall discussion, he concludes with “just override”