New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Thoughts about using prettier #1548
Comments
While I'd be quite interested to read the research from the last item above, and would be very interested in hearing a concrete example from the third item — at this time Airbnb does not use prettier, and does not recommend its use. |
Thanks for the quick reply. Unfortunately this reply is not nearly so short 😢
Instead I'm simply recommending extending
We've been using Airbnb's style guide with
That said, that's a bit of a cheats argument and I'm guessing not what you were after. The indentation rule in ESLint has gone through massive rewrites in ESLint 4. That said, it still won't say that // good
foo(arg1, arg2, arg3, arg4);
// bad
foo(
arg1,
arg2,
arg3,
arg4,
);
// bad
foo(reallyLongArg(), omgSoManyParameters(), IShouldRefactorThis(), isThereSeriouslyAnotherOne());
// good
foo(
reallyLongArg(),
omgSoManyParameters(),
IShouldRefactorThis(),
isThereSeriouslyAnotherOne()
); This is the trivial example often cited, but it goes much further, how do you break up ternaries on multiple lines, how do you indent arrow functions in big promise chains, etc. With prettier I don't need to remember, I just hit save and it reformats it in a way that looks pretty good. I used to think that developers should worry about all aspects of code style, but having tried prettier for a few months now I'm glad to now have to worry about it.
The only two options you'd need for prettier are It's hard for me to know exactly what is different between using prettier to manage "style" and airbnb's rules. One way to see the differences would be to study the source code of Another way (what I've done below) is see the practical differences we have on our codebase between the two. Please note that we don't use JSX and so I can't speak of any differences there. Running prettier over our codebase for the first time reformatted a lot of whitespace changes that Airbnb's style guide didn't enforce. As for actual differences (as in places where the two disagree), the main one we found in our codebase (by number of lines) is: // airbnb (kinda)
const foo = function (arg, arg2) {
// prettier
const foo = function(arg, arg2) { That said, 7.1 of the airbnb style guide forbids function declarations like this, we just haven't cleaned all of ours up yet 😰. As for the actual differences, these are all that I have found: /// space-in-parens
// airbnb
for (let i = 0; i < foo.length;) {
// prettier (note extra space after the last `;`
for (let i = 0; i < foo.length; ) { // wrap-iife
// airbnb
(function init() {
// Body
}());
// prettier
(function init() {
// Body
})(); // indent
// airbnb
const foo = bar
? ''
: {
property,
anotherProperty,
};
// prettier
const foo = bar
? ""
: {
property,
anotherProperty
}; // indent
// airbnb
this.foo
.getStuff(
{
bar
},
{},
)
.then()
// prettier
this.foo
.getStuff(
{
bar
},
{}
)
.then(); One more that I will add is that is seems that using // no-confusing-arrow
// airbnb
foobar = someList.reduce(
(foo, bar) => { return bar === '' ? foo : bar; },
'',
);
// prettier with eslint-config-prettier?
foobar = someList.reduce(
(foo, bar) => (bar === '' ? foo : bar),
'',
); So to summarise, the conflicts between the two style guides all seem very minor and I do think that adding prettier as an ESLint rule would actually work really well as part of Airbnb's style guide. That said, it's not my guide, so all I can do is ask you to consider it. |
I'd say the best use of anyone's time would be to PR any "missing" autofixes into eslint - with those, prettier serves no purpose, and there'd be no need to add it. |
@ljharb is that feasible with the current eslint autofix primitives? See eg this comment from the eslint repo owner. Given the core functionality of prettier - line length - I'm not sure that any eslint fix could be made in a form other than "run prettier and use it as an eslint rule", which is what eslint-plugin-prettier accomplishes. It might be worth your time to experiment with the tool; I think you may find it interesting. Perhaps Airbnb could fork prettier, and align its output with your own style. I imagine it would be popular. |
@ljharb if you haven't read the Haskell paper which outlined the core technique prettier uses, you might enjoy it. It's actually not terribly involved. |
Forking without intent to upstream, nor without intent to make a significantly different product, isn't particularly good for the ecosystem. That comment is from one (of the many) eslint maintainers (not an "owner"). Nothing about that comment suggests these things are impossible; on the contrary, it suggests that making those changes would be a much better use of time and effort than reinventing the wheel with a new tool. If improving eslint beyond a certain point isn't feasible, so be it - but we're a) nowhere near that point, and b) a better tool would use eslint configs, the defacto standard for declaring code style, and not just impose a minimally configurable and arbitrary style rubric. |
I think a lot of people would love to see a tool with the power of prettier, the configurability of eslint, and the opinions of Airbnb. I know I would. You might do a little more research into the nature of prettier before claiming that its core functionality is possible with existing eslint tools, however. |
I believe all the research you're referring to is about what's possible, not what's impossible. I've yet to see any examples of something with prettier that's never possible with eslint; and if someone can provide one, then that'd be a great motivation to change eslint itself to have a similar approach as prettier does. |
Mostly I meant its implementation, not its capabilities. Any program can be built with any Turing-complete tool, but elegant architectures can get the job done better. I think you'd enjoy a read of its guts if you haven't given them a gander (I know you're busy, so this would go in the "optional pleasure reading" bucket). I'm sure you'd find the source approachable. As @aboyton mentioned above, the key breakthrough of prettier is expanding/collapsing long expressions across lines based ~purely on AST. I think many people in the industry would be quite impressed if you were able to solve this problem without primitives like those prettier uses. |
To be clear, I do agree with you that it'd be possible to use those primitives as individual eslint rules, and in some ways preferable. Iit'd just be very difficult to build. (It'd also be too slow for a formatOnSave editor integration (which, while not something you recommend, is a very popular feature)). |
Sorry for the delay, I've been away and a busy with work. It's 100% possible to make ESLint rules format code like prettier does, but the only real way to do so is to reimplement prettier, or to use prettier as an ESLint rule (which is what To demo how much stricter prettier is with styles compared to standard ESLint rules I've run prettier on |
Many of us have been using prettier for a while now and have found it wonderful for formatting code.
Prettier obviously doesn't replace most of the lint rules in Airbnb's style guide (c.f. #1307), but it can definitely compliment it by freeing up a developer to not have to worry about code style (where should line breaks happen, how much should this be indented) and instead worry about more important things (like not using
for-of
#1122). The prettier website has a bunch of other people's reasons why they like prettier.Obviously people can use prettier with Airbnb's style guide currently (as many of us have been), but I was wondering if Airbnb had considered making this the default.
The text was updated successfully, but these errors were encountered: