refactor(bundler): New Gemfile parser based on "tree-sitter" #28403
Conversation
zharinov
changed the title
|
Okay, now it's obvious that particular |
|
Or, another possibility that it has something to do with our aggressive CI caching |
|
Nah, it's not good enough 😂 |
I don't know, the local setup on my M1 machine works fine for both 18 and 20 |
|
Starting from 
The problem is that some (e.g. |
| @@ -135,10 +135,10 @@ describe('modules/manager/bundler/extract', () => { | |||
| 'Gemfile', | |||
| ); | |||
| expect(res?.deps).toMatchObject([ | |||
| @@ -0,0 +1,327 @@ | |||
| import Parser, { Query, SyntaxNode } from 'tree-sitter'; | |||
There was a problem hiding this comment.
it seems it's something like antlr?
does it make sense to use it for more languages?
There was a problem hiding this comment.
Yes, it is similar to Antlr, now it's gaining popularity among text editor enthusiasts (specifically, Neovim), and it powers GitHub's syntax highlight.
There was a problem hiding this comment.
does it make sense to use it for more languages?
It supports quite a bit of languages: https://tree-sitter.github.io/tree-sitter/
The problem is, like this Ruby implementation, many of them are not compatible with the recent node binding.
Co-authored-by: Michael Kriese <michael.kriese@visualon.de>
Changes
This PR introduces "tree-sitter" for parsing dependencies from complex languages.
Context
The current regex-based implementation is hard to maintain.
It blocks implementation of #4789, which should be straightforward with this new parsing approach.
Documentation (please check one with an [x])
How I've tested my work (please select one)
I have verified these changes via: