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

Static analysis/linting APIs #1829

Closed
kittens opened this Issue Jun 25, 2015 · 9 comments

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

This comment has been minimized.

Show comment
Hide comment
@kittens
Member

kittens commented Jun 25, 2015

cc @hzoo

@hzoo

This comment has been minimized.

Show comment
Hide comment
@hzoo

hzoo Jun 26, 2015

Member

Excited to see where this goes!

Member

hzoo commented Jun 26, 2015

Excited to see where this goes!

@kittens

This comment has been minimized.

Show comment
Hide comment
@kittens

kittens Jul 14, 2015

Member

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

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

This comment has been minimized.

Show comment
Hide comment
@hzoo

hzoo Jul 14, 2015

Member

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

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

This comment has been minimized.

Show comment
Hide comment
@nzakas

nzakas 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?

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 milestones: 6.x, 6.0.0 Oct 28, 2015

@hzoo hzoo removed umbrella labels Jan 20, 2016

@hzoo

This comment has been minimized.

Show comment
Hide comment
@hzoo

hzoo Oct 4, 2016

Member

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

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

This comment has been minimized.

Show comment
Hide comment
@cpojer

cpojer Oct 5, 2016

Member

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.

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

@hzoo

This comment has been minimized.

Show comment
Hide comment
@hzoo

hzoo Feb 8, 2017

Member

Updates with this stuff:

  • Babel can take in a different parser/generator including both recast/prettier for codemods
  • Babylon will have an ESTree plugin soon (so we can remove a lot of the AST node checking in babel-eslint babel/babylon#277
Member

hzoo commented Feb 8, 2017

Updates with this stuff:

  • Babel can take in a different parser/generator including both recast/prettier for codemods
  • Babylon will have an ESTree plugin soon (so we can remove a lot of the AST node checking in babel-eslint babel/babylon#277
@hzoo

This comment has been minimized.

Show comment
Hide comment
@hzoo

hzoo Mar 19, 2017

Member

Not sure what we should do with this issue anymore. If anything we want: less hacks in babel-eslint (partially done already), and maybe better interop with babel/eslint (possibly passing ast between or running eslint rule in babel, etc.

Member

hzoo commented Mar 19, 2017

Not sure what we should do with this issue anymore. If anything we want: less hacks in babel-eslint (partially done already), and maybe better interop with babel/eslint (possibly passing ast between or running eslint rule in babel, etc.

@hzoo hzoo closed this Mar 19, 2017

@lock lock bot added the outdated label May 5, 2018

@lock lock bot locked as resolved and limited conversation to collaborators May 5, 2018

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.