Thanks for suggestion.
Of course there is contributing guide. https://ast-grep.github.io/contributing/add-lang.html

That said, I would think Terraform and HCL will be better supported by custom language registration?

https://ast-grep.github.io/advanced/custom-language.html

Thanks. Wasn't aware of that capability. I'll take a look.

@HerringtonDarkholme can you articulate why you feel a custom language registration is a better fit for HCL? I can understand wanting to keep scope down, but requiring folks to compile their own stuff is absolutely going to be a barrier to use (especially, but not exclusively, when people (me) want to use this in automated pipelines)

@ThisGuyCodes ast-grep cannot bundle all languages in its binary. Built-in language should have enough community usage to deliver max impact with limited binary size.

If HCL has enough users upvote for inclusion in ast-grep, we will definitely consider it.

Now it is reasonable to accept the HCL support PR, as many users are requesting it.

However, I will not work on it myself but expect community PR like
#2107 and #2103

You can use https://ast-grep.github.io/advanced/custom-language.html

Supported! #2107

ast-grep at the moment does not support registering multiple binaries at the moment. instead, it relies on installation time binary picking up. https://github.com/ast-grep/langs

I wonder what is your setup. Are you commiting pre-compiled binary into the monorepo (fbcode?) So your users will not have a installation time.

I can give it a look if that's the use case.

So for the ast-grep binary itself we do keep it precompiled in the repository. Every linter is effectively a binary that we have a contract with. People work with it with Macs, Windows, Linux machine and we expect exactly the same binary call to succeed on all platforms without users having to install anything on their machines. (Simplified it's ast-grep scan --config <path_to_config>). So everything is fine with built-in languages. If we register a custom language the config requires static configuration with concrete parser.so file which is not portable. At the moment we're trying to use ast-grep in the repository with LFS so we're ok to just add an .so file in the repository. But would like another solution if we were to allow custom languages in fbcode.

One way this can be fixed in my opinion is that if in addition to "libraryPath" we get "libraryLookupBinary" and ast-grep would execute it to get the path to the parser from stdout. Then the binary (most likely shell script) would be able to handle platform specifics and pick the right parser for the os/platform.

Also adding parameters to fully configure "customLanguages" via command line arguments can help too

Thanks for the information. Using libraryLookupBinary is probably too heavy, how about make libraryPath an object like

libraryPath:
  aarch64-apple-darwin: darwin.so
  aarch64-unknown-linux-gnu: linux-gnu.so
  i686-pc-windows-msvc: windows.so

So ast-grep can resolve the dynamic lib using the target triple defined by rust. https://github.com/dtolnay/target-triple

This will need some time for ast-grep to implement. At the same time, an alternative way is to maintain several different YAML configuration and having a wrapper script to invoke different binary like ast-grep-aarch64-linux-gnu scan --config aarch64-linux-gnu.yml.

tracked by #2013

shipped in 0.38.3

generally ast-grep CLI now only accepts grammar from these sources:

• tree-sitter org
• tree-sitter-grammar org
• official language org
  tree-sitter-groovy comes from an individual repo and ast-grep will wait for some official endorsement.
  Plus, if Groovy is supported, should ast-grep support other build script language? say cmake. Or other config language like HCL

Groovy isn't just a build script language, it's another JVM language like Kotlin or Scala (but mostly dynamically typed). It just happens to have been used in Jenkins (and Gradle). But I take your point about official/trusted sources.

I have submitted https://issues.apache.org/jira/browse/GROOVY-11705 requesting an official tree-sitter grammar for Groovy.