Node -> Tokens navigation, token list navigation

[mdevils]

This is a the start of 2.x work. We can significantly simplify new rules using this kind of navigation.

[mdevils]

/cc @mikesherov @markelog

[mdevils]

@mikesherov Can you take a look please, so I can continue to work on 2.0?

[markelog]

as discussed, i would add tests for new methods, we probably could start using some coverage tool for it too :-)

[mikesherov]

Agreed with @markelog, if we're going to land these new methods, tests and an actual implementation in at least one rule would be nice. Other than that I have a few comments I'll leave.

[mikesherov]

findPrevToken

[markelog]

actual implementation in at least one rule would be nice

@mdevils already find use of them – 6733799

[mikesherov]

@mdevils already find use of them – 6733799

Yes, but perhaps land them them with this PR?

[markelog]

Yes, but perhaps land them them with this PR?

That is the idea

[coveralls]

Coverage increased (+0.17%) when pulling 55e2a45 on mdevils-2.x-navigation into 0f281cf on 2.x.

[mdevils]

• Integrated coverage: Coverage integration #557
• Renamed methods: findTokenBackward, findTokenForward -> findPrevToken, findNextToken.
• Wrote tests for all new methods.

[mikesherov]

👍 from me. This looks good to land for 2.0

[markelog]

Same here

[markelog]

I wonder if we can merge this to master branch, it seems we could already start using it

[mdevils]

Well, we can.

[markelog]

So if that returns undefined, than customer of that method should check for it before using? So i can't just do if (getTokenByRangeStart(...).value === '['), i would need to do something like this:

var token = getTokenByRangeStart(...);

if (token && token.value === "["){
...
}

Maybe, for convenience sake, it could return some fake token instead of undefined, like

{ 
  type: '',
  value: '',
  range: [ -1, -1 ],
  loc: { start: { line: -1, column: -0 }, end: { line: -1, column: -1 } },
  _tokenIndex: -1 
}

[qfox]

type: 'fake' :-) agreed with fake token, but probably we should be more concrete on this.

[markelog]

This token isn't there, so it's not really fake, such situations might exist if current token is first or last token in the tree

[mdevils]

For now I'm not sure there can be situation with no token (if you pass real node range).

[markelog]

@mdevils that is mostly for the getNextToken/getPrevToken, here, just for the consistency

[markelog]

Also, how about iteratePunctuatorsByName, would ease those rules that have to check through tokens?

Has a downside, since it will reflect on performance.