Static analysis/linting APIs #1829

Open
kittens opened this Issue Jun 25, 2015 · 7 comments

Projects

None yet

5 participants

@kittens
Member
kittens commented Jun 25, 2015

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.

@kittens
Member
kittens commented Jun 25, 2015

cc @hzoo

@kittens kittens self-assigned this Jun 25, 2015
@kittens kittens added this to the 6.0.0 milestone Jun 25, 2015
@hzoo
Member
hzoo commented Jun 26, 2015

Excited to see where this goes!

@kittens
Member
kittens commented Jul 14, 2015

Ok so I've been thinking about linting a lot recently. There's currently two approaches:

  1. Better integration with a tool like ESLint.
  2. Roll our own.

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.

cc @nzakas

@hzoo
Member
hzoo commented Jul 14, 2015

@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.

@nzakas
nzakas commented Jul 15, 2015

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?

@kittens kittens modified the milestone: 6.x, 6.0.0 Oct 28, 2015
@hzoo
Member
hzoo commented Oct 4, 2016

Not sure what we should do with this, but some updates:

  • st ill no integration with flow/typescript on babel's side
  • eslint has autofix
  • babel-eslint still does monkey-patching
  • estraverse accommodates unknown nodes
  • @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. - this is possible with #3561 (ability to use recast parser/generator)

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

@cpojer
Member
cpojer commented Oct 5, 2016

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.

@danez danez removed this from the 6.x milestone Jan 17, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment