Fix blade support

[sidp]

This PR fixes support for blade templates, as reported in #70.

The problem:
Blade templates are parsed with tree-sitter-php. The parser requires code to be within opening and closing <?php, ?> tags. Blade doesn't use these, so the parser was not able to extract strings from blade files.

The solution:
Use tree-sitter-php in the php_only parser mode, which parses top-level statements without opening and closing tags. This mode is not available in the version of tree-sitter-php that was previously used, so it needed to be updated.

Summary of changes:

• Updated tree-sitter depencencies. I had to update all of them to resolve peer-dependency issues that arose from updating only tree-sitter-php.
• Added tests for blade templates using both {{}} echo statements and @php directives.
• Added utility function to get file extensions, that takes "blade.php" into account.
• Corrected the glob pattern for excluding blade files when the --skip-blade setting is used.

Tell me if you have any comments or questions!

close #70

[erikyo]

Thank you for keeping the code well-organized 🎉

[sidp]

@erikyo Happy to help. Thank you for reviewing so quickly!

[erikyo]

Thanks to you @sidp! ☺️

I took the opportunity to fix an issue that arose with the tree-sitter update... in short, with the latest version (> 22) it seems that when using parser.parse some files that are too large return an error like this Error: Invalid argument

I am investigating why, and in the meantime I wrapped that function inside a try catch (#73), but I would like to understand in which cases the 'parse' function fails

[sidp]

I see! It seems like Error: Invalid argument is thrown when the input string exceeds the buffer size of tree-sitter. I generated a >32KB PHP file that fails, but increasing bufferSize past that allows the file to be parsed. I guess that increasing the bufferSize across the board would unnecessarily increase memory usage. Given that the input source is a string perhaps bufferSize could be dynamically increased to some reasonable amount to at least alleviate the issue? Not sure about potential performance implications.

const fileSize = Buffer.byteLength(sourceCode, "utf8");
const maxFileSize = 1024 * 128;

if (fileSize > maxFileSize) {
	console.error(`File size of ${filepath} exceeds ${maxFileSize / 1024}KB limit.`);
	return;
}

const bufferSize = Math.min(fileSize, maxFileSize) + 32; // 32 bytes of padding

// parse the file
const tree = parser.parse(sourceCode, undefined, {
	bufferSize,
});

[erikyo]

Nice catch! Can you add your code to PR #73?

One idea: could we check if the file exceeds the limit and in that case make the buffer size dynamic? That way, for files that exceed the limit, we could still attempt to parse them by setting the buffer size to match the actual file size (plus padding). This way, larger files would not be completely blocked and the performance impact would only occur when actually needed.

Something like:

const fileSize = Buffer.byteLength(sourceCode, "utf8");
let bufferSize = 1024 * 128;

if (fileSize > bufferSize) {
	console.warn(`File size of ${filepath} exceeds ${bufferSize / 1024}KB, using dynamic buffer size.`);
	bufferSize = fileSize + 32; // Dynamic buffer for large files
}

const tree = parser.parse(sourceCode, undefined, {
	bufferSize,
});

What do you think of this approach?

[sidp]

Sounds reasonable to me! This would however allow the buffer size to be set to very high numbers. Perhaps it makes sense to have a hard cap somewhere? V8 has a 1 GB limit on strings so I think that this would otherwise be the limiting factor. I would also keep 32 KB as the default to not change the memory usage under normal conditions.

I can't push to the 1.6.2 branch but I can make a PR to it with these changes 😊

[erikyo]

yep sorry, create a new PR and then i'll take care about merging into the current dev branch. thanks again!

This would however allow the buffer size to be set to very high numbers. Perhaps it makes sense to have a hard cap somewhere?

Good point about the potential memory issues! A hard cap makes sense to prevent excessive memory usage, What do you think about 100MB as a hard cap? Or we should use totalmem and set it dynamically?