Skip to content
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

buildifier: let user hint file type via comment #1276

Open
sluongng opened this issue Jun 13, 2024 · 0 comments
Open

buildifier: let user hint file type via comment #1276

sluongng opened this issue Jun 13, 2024 · 0 comments

Comments

@sluongng
Copy link

A typical Bazel setup would involve several deps.bzl files, which declare several http_archive and other repository rules that are later loaded in WORKSPACE. In the future, with BzlMod support importing smaller files into MODULE.bazel, we expect to also have multiple deps.bzl files loaded there as well.

To effectively lint these files, the user would need to specify the correct file type. For example, a deps.bzl file that is loaded in WORKSPACE should be treated as WORKSPACE type and not bzl type.

Today, buildifier chooses the parser type based on (a) user-specified value in -type flag or (b) the file name. Given that (a) is not automatable, and (b) does not apply in many cases, there needs to be a better solution.

I think it would be best if we allow something like

# buildifier: type=WORKSPACE

that goes on the very top of the file so that we can switch the result file type after parsing the Starlark file.

See the code at

buildtools/build/lex.go

Lines 157 to 169 in 80f1f68

func Parse(filename string, data []byte) (*File, error) {
switch getFileType(filename) {
case TypeBuild:
return ParseBuild(filename, data)
case TypeWorkspace:
return ParseWorkspace(filename, data)
case TypeModule:
return ParseModule(filename, data)
case TypeBzl:
return ParseBzl(filename, data)
}
return ParseDefault(filename, data)
}
for more context.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant