81–90 of 159 posts
The idea is to have a common AST (with parsers for each language) which keeps track of whitespace/comments/etc and then share a ton of logic by writing writing code at the AST layer.
You can use pfff to pretty print according to your style needs. Also supports a bunch of other neat things such as search/replace.
How does this compare to clang-format, which also formats JavaScript and also (to use one of the features highlighted in the article) obeys line length?
I appreciate the emacs bindings [0]! Between this and eslint+flycheck I will feel less envious of Visual Studio Code's editor environment (if only there were a way to leverage some of its fantastic IntelliSense from emacs...) [0] https://github.com/jlongster/prettier/tree/master/editors/em...
I think that vscode uses the typescript language server behind-the-scenes for plain javascript analysis.
After using Elm and the elm-format package in Emacs for the last few weeks I can say that not having to format the source and just letting your editor do it for you on save or via a command is so very nice. This is a trend that I feel is going to catch on across any language that can support it. It makes trivial decisions and arguments about formatting a thing of the past.
Personal code formatting preferences is a problem. Devs should just let go of it, once it applies automatically your preferences quickly change.
You can even wire up GitHub etc repos to automatically reject pull requests that add pointless formatting preferences someone will pointedly defend.
After using Elm and the elm-format package in Emacs for the last few weeks I can say that not having to format the source and just letting your editor do it for you on save or via a command is so very nice. This is a trend that I feel is going to catch on across any language that can support it. It makes trivial decisions and arguments about formatting a thing of the past.
It's almost crazy to think this already isn't just a thing. Why is this just coming to a head now, after all these years of carrying on over code formatting?
huh? I've been using emacs with WebMode + tide + FlyCheck and it supports jsx just fine. Moreover, tide[1] provides great support for plain javascript (I've used it extensively on a ES6 codebase with great results).
Earlier quoted context omitted.
It's almost crazy to think this already isn't just a thing. Why is this just coming to a head now, after all these years of carrying on over code formatting?
I'm not convinced it is just coming to a head now. I've seen automatic/forced formatting on projects at least as far back as 2000, when I entered the workforce.
myPromise.then(() => {
// ...
}).then(() => {
// ...
}).catch(() => {
// ..
});
);
foo(
reallyLongArg(),
omgSoManyParameters(),
IShouldRefactorThis(),
isThereSeriouslyAnotherOne()
);
foo(reallyLongArg(), omgSoManyParameters(), IShouldRefactorThis(),
isThereSeriouslyAnotherOne());
Stated differently, is this meant to be very opinionated in hopes that all JS would follow a uniform style? I think that can work for Go since it was like that from Day 1. For JS, though, it has been out for so long that many teams have developed their own preferred style. I suspect that most of them would avoid an opinionated formatter that differs in a few small ways from their in-house format, if only because it seems silly to break diffs and git blame for a sweeping formatting change.
If I personally prefer the second Promise chain: myPromise.then(() => { // ... }).then(() => { // ... }).catch(() => { // .. }); and if I also prefer the Lisp-like approach and hate putting: ); on its own line, am I part of the problem? What if my whole team uses that style? For example, we would write: foo( reallyLongArg(), omgSoManyParameters(), IShouldRefactorThis(), isThereSeriouslyAnotherOne() ); as: foo(reallyL…
The version control issues might be a blocker though. It would be neat if git had a way to do diffs at the syntax tree level.
If I personally prefer the second Promise chain: myPromise.then(() => { // ... }).then(() => { // ... }).catch(() => { // .. }); and if I also prefer the Lisp-like approach and hate putting: ); on its own line, am I part of the problem? What if my whole team uses that style? For example, we would write: foo( reallyLongArg(), omgSoManyParameters(), IShouldRefactorThis(), isThereSeriouslyAnotherOne() ); as: foo(reallyL…
I avoid opinionated lint rules because it's annoying to retrain yourself, but if my editor does all the work and it's readable enough I'd love to adopt this or something like it. The version control issues might be a blocker though. It would be neat if git had a way to do diffs at the syntax tree level.