Not happy with the current APIs available for linting, they're verbose and work on token streams. Complex static analysis is very easy with Babel's path API so it's trivial to add linting support. Long term would like to get rid of babel-eslint as it's extremely hacky.
Excited to see where this goes!
Remove babel-jscs dependency for now
Ok so I've been thinking about linting a lot recently. There's currently two approaches:
Babel already has a ton of methods that allow easy static analysis of very complex trees. In the future there'll hopefully be integration with Flow which would allow easy access to a ton of metadata about program execution and the entire dependency graph which means linting can extend far beyond just style and into structural pattern matching.
The hard part of linting is basically just static analysis. Babel already has that covered which means that there's only two additional things that need to be implemented to get linting and that's some way to mark a node and a way to report it to the user. These two are easy and would just involve a single method call to "mark" a node with an error and a UI to report it.
@cpojer is interested in extending Babel to have much better codemod support for things like automated refactoring, this basically means that the automatic fixing of tools like JSCS fit in perfectly with this goal.
I see only issues with better integration with ESLint, Babel already has plugins, easy static analysis APIs, solid scope tracking etc. Monkey patching ESLint as seen in babel-eslint, while it works surprisingly well, is an extreme hack. I don't feel comfortable encouraging use of such a hack. The only way I can see ESLint ever getting the desired level of integration and stability for Babel would be if it was rolled into core (this would be extremely intrusive), and even then there are issues with interoperability and more.
@mdevils has been working on https://github.com/mdevils/cst (now using babel) to help with making autofixing easier in jscs jscs-dev/node-jscs#1502 (comment) since we could only do simple changes with tokens (thus only supporting mostly whitespace fixes although it covered a lot of the rules).
Yeah being able to support automated refactoring like in https://github.com/gkz/grasp and https://github.com/facebook/jscodeshift would be great - I know react has https://github.com/facebook/react/tree/master/packages/react-codemod to update code when react updates to a new version and the api changes. Making that kind of tool easy would encourage more users to update and for devs to be more confident in making changes.
ESLint is also working on code fixing, for the record.
I dont see enough details here to be able to comment on an integration, so I'll explain how I see things.
ESLint basically runs off of three things: Espree (or another parser), estraverse for traversing the AST, and escope for scope analysis. Part of why babel-eslint is a pile of hacks is because it uses the parser mechanism to reach into ESLint and change estraverse and escope, which is something that extension mechanism was never intended to do.
From my point of view, the only thing preventing a non-hacky integration is to just make formal integration points for traversal and scope analysis. I've even been thinking about moving to a traversal system that is generic so we can always accommodate unknown nodes, so maybe that's not even necessary.
My question to you is: what are the "static analysis tools" from Babel that you'd want to use?
Not sure what we should do with this, but some updates:
Not sure how we would intergrate but @nzakas is working on https://github.com/eslint/typescript-eslint-parser and https://github.com/babel/babel-eslint is still patching estraverse/escope for flow/new syntax
I was hoping that we could eventually kill recast and have all the pretty-printing features live in babel itself. jscodeshift would then just be an API wrapper for babel transforms.