question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Support ${workspaceFolder} in buildifier & bazel paths

See original GitHub issue

I can add a bazel path relative to the vscode workspace root, but I can’t do the same for a buildifier path.

Here’s the buildifier path code which is not relative to the workspace root: https://github.com/bazelbuild/vscode-bazel/blob/d2e0b7dd9f387ee66829e960b2016dba474b2df8/src/buildifier/buildifier_availability.ts#L33

Here’s the bazel path code which is relative to the workspace root: https://github.com/bazelbuild/vscode-bazel/blob/8fbcd2769228731827c4b7c2ba3bbc36bb1f5e34/src/bazel/tasks.ts#L72

These should obviously use the same code and both should support paths relative to the workspace root 😃

Note: most other vscode extensions support putting ${workspaceRoot} in the path to refer to the vscode workspace root. For example, clangd, protoc, shellcheck, and python all do this, and I’m sure many more.

Issue Analytics

  • State:closed
  • Created 4 years ago
  • Reactions:1
  • Comments:6 (1 by maintainers)

github_iconTop GitHub Comments

3reactions
dapiriancommented, Feb 7, 2020

It’s extremely common for extensions to support either relative paths from the workspace root or something like $workspace_root… so, do whatever they do? Perhaps just where the workspace file actually is?

2reactions
joneshfcommented, Apr 2, 2021

Is there a solution here that doesn’t require absolute paths for only the buildifier binary?

In case it’s not clear, we have to have settings like:

{
    "bazel.buildifierExecutable": "/Users/some-user/some-arbitrary-path-to-the-repo/tools/buildifier",
    "bazel.executable": "tools/bazel"
}

We can write the bazel.executable setting once and share it amongst a team, but we cannot write the bazel.buildifierExecutable setting once and share it amongst a team. The absolute path is almost never the same between different machines: platforms, users, personal preference, etc.

Instead, it would be ideal if we could use the same relative path support for buildifier that we can currently use for bazel:

{
    "bazel.buildifierExecutable": "tools/buildifier",
    "bazel.executable": "tools/bazel"
}
Read more comments on GitHub >

github_iconTop Results From Across the Web

Buildifier
buildifier is a tool for formatting bazel BUILD and .bzl files with a ... Buildifier supports the following file types: BUILD , WORKSPACE...
Read more >
Debugging with Bazel in Visual Studio Code with Ubuntu
The following configuration uses the "official" paths in bazel-bin/ : ... "${workspaceFolder}/bazel-bin/example/example.runfiles/__main__", ...
Read more >
Bazel Build with Visual Studio Code
In this blog post I'll go over the process of making Bazel work well ... time: 49.794s, Critical Path: 4.01s INFO: 2 processes:...
Read more >
buildifier - Pants build
Pants supports running Buildifier on your Pants BUILD files for several reasons: You might like ... adopting Pants from Bazel, and are already...
Read more >
Workspace Rules - Bazel
This rule creates a Bazel repository by creating a WORKSPACE file and subdirectory containing symlinks to the BUILD file and path given. The...
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found