search

millermedeiros / esformatter

ECMAScript code beautifier/formatter
MIT License
970 stars 91 forks source link

merge with eslint #452

Closed graingert closed 8 years ago

graingert commented 8 years ago

eslint 3.0.0 allows for non-whitespace changes, is it worth merging with eslint, just like JSCS?

davidpfahler commented 8 years ago

If this is possible, it would be awesome. However, how would such a merger be done? As far as I understand it, ESLint applies fixes based on nodes and with text replacement methods. This is entirely different from esformatter's approach as I understand it, which parses source to AST back to source. Not matter if there is an error in your code, esformatter always reformats the entire file, ESLint only fixes what it finds is wrong. Please correct if I'm wrong. I'd be happy to be wrong in this case ;)

graingert commented 8 years ago

@davidpfahler JSCS uses and ESLint will use https://github.com/cst/cst

If esformatter also switched it would be an easier merge. Maybe mention this in the eslint tracker?

davidpfahler commented 8 years ago

@graingert I've read that ESLint would be using cst but never saw an "official" roadmap. CST would, of course, be the right technology for all these tools and then formatting could be done based only on ESLint rules, which I think would make the most sense. Can you point me somewhere regarding ESLint and CST? I'd be happy to contribute and test.

PS: Also see https://github.com/eslint/eslint/issues/5040#issuecomment-174588771. Is CST support really coming?

millermedeiros commented 8 years ago

would love for ESLint (or any other project) to support/fix ALL the things; but to be honest, I think that there is a huge value in having a linter separate from the formatter...

we're basically approaching the problem from 2 ends of the spectrum. ESLint is focused in finding things that don't match the guidelines and later implementing the "fixer" for it; while esformatter cares about making the code compliant with the guidelines, and later giving you an option to do a "diff" to check what is different:

ce7tsjmveaaaqk4

esformatter approach happens on a single step, which means we don't need to implement the logic twice (one to detect the error, and one to fix it...); sometimes you also don't want to fix all the lint errors, but you still want to fix all white spaces, line breaks and indentation...

IMO linters should care about potential bugs in the code (or rules that should be followed), while an automatic code formatter should care "mostly" about cosmetic things (adding/removing semi-colons, indentation, line breaks, white spaces, etc..)

I still think that esformatter approach is not perfect, but is the best structure that I've seen related to non-destructive manipulation of a language as flexible as JavaScript... - I highlighted a few issues related to the CST proposal a couple years ago before the CST project started (search for my name on the closed issues here: https://github.com/getify/concrete-syntax-tree/issues/)