Coder Social home page Coder Social logo

bazelbuild / vscode-bazel Goto Github PK

View Code? Open in Web Editor NEW
238.0 28.0 77.0 711 KB

Bazel support for Visual Studio Code

Home Page: https://marketplace.visualstudio.com/items?itemName=BazelBuild.vscode-bazel

License: Apache License 2.0

TypeScript 95.23% Shell 1.80% JavaScript 2.97%
bazel visual-studio-code

vscode-bazel's Introduction

Bazel plugin for Visual Studio Code

Build Status

This extension provides support for Bazel in Visual Studio.

Features

  • Syntax highlighting
  • Bazel Targets tree displays the build packages/targets in your workspace
  • CodeLens links in BUILD files to directly launch a build or test by simply clicking on the targets
  • Buildifier integration to lint and format your Bazel files (requires that Buildifier be installed)
  • Bazel Task definitions for tasks.json
  • Coverage Support showing coverage results from bazel coverage directly in VS Code.
  • Debug Starlark code in your .bzl files during a build (set breakpoints, step through code, inspect variables, etc.)

Configuring the Extension

This extension adds a Bazel section to the extension settings in Visual Studio Code. If you have Bazel installed in a location that is not on your system path or if you wish to use a different version in the IDE, you should set the Bazel: Executable setting to the location of the Bazel executable.

Similarly, the Bazel: Buildifier Executable setting can be configured if you install Buildifier in a location that is not on your system path.

When Buildifier is installed, the Format Document command in Visual Studio code will reformat BUILD, WORKSPACE, .bzl, and .sky files using the tool and will display lint warnings from those files as you type. By default, this extension does not automatically fix lint warnings during formatting, but you can opt into this by enabling the Bazel: Buildifier Fix on Format setting.

Using a separate output base

By default this extension will use the default output base for running queries. This will cause builds to block queries, potentially causing degraded performance. In Bazel versions since 7.1 it is safe to disable this by changing the bazel.queriesShareServer setting to false. In earlier versions it can be safely disabled after adding the convenience symlinks to .bazelignore, for example:

bazel-myreponame
bazel-bin
bazel-testlogs

See #216 and bazelbuild/bazel#106539.

Using the Starlark Debugger

Currently, the Starlark Debugger can be used by right-clicking a build target in the Bazel Build Targets view and selecting "Build Target with Starlark Debugger". This will start the build inside the Visual Studio Code debugger (output will be redirected to the Debug Console pane) and it will pause on any breakpoints hit during execution.

When a Bazel thread is paused, you can step through Starlark code, add watch expressions, and execute arbitrary statements by typing them in the input area of the Debug Console.

Clicking the "Stop" button in the debugger will kill the Bazel process being debugger, allowing you to halt the current build. The Bazel server, however, will continue running.

Using a language server (experimental)

This extension can use a language server for various features, such as go to definition and completions. There are currently two compatible language servers:

  • bazel-lsp is based on Facebook's Starlark language server and extends it with additional, Bazel-specific functionality.
  • starpls is an implementation based on rust-analyzer which also provides Bazel-specific functionality.

In general, you need to install the language server binary and then set the bazel.lsp.command setting. See the README of the corresponding repo for more specific setup instructions.

We can't currently make any recommendation between these two. Both are under active development and are rapidly gaining more functionality.

Bazel tasks

Bazel tasks can be configured from the tasks.json using the following structure:

{
  // See https://go.microsoft.com/fwlink/?LinkId=733558
  // for the documentation about the tasks.json format
  "version": "2.0.0",
  "tasks": [
    {
      "label": "Check for flakyness",
      "type": "bazel",
      "command": "test",
      "targets": ["${input:pickFlakyTest}"],
      "options": ["--runs_per_test=9"],
    },
  ],
  "inputs": [
    {
      "id": "pickFlakyTest",
      "type": "command",
      "command": "bazel.pickTarget",
      "args": {
        "query": "kind('.*_test', //...:*)",
        "placeHolder": "Which test to check for flakyness?",
      },
    },
  ],
}

Coverage support (Experimental)

For all coverage tasks, the coverage results are automatically loaded into VS Code upon completion of the task. E.g., you could define your own task to display the coverage provided by your integration tests using the following task definition:

{
  "label": "Show test coverage from integration test",
  "type": "bazel",
  "command": "coverage",
  "targets": ["//test/integration/...", "//cpp/test/integration/..."],
  "options": ["--instrumentation_filter=.*"],
}

You might need additional Bazel options to get the intended coverage results. In particular if are using remote builds, you might need to use the --experimental_split_coverage_postprocessing and --experimental_fetch_all_coverage_outputs options. See the documentation on Code Coverage with Bazel for more details.

Code coverage support in this extension is still rather fresh and might still have rough edges. It was tested with the Java, C++, Go and Rust rules. In case you are using the code coverage integration with any other language (Python, Swift, Kotlin, Scala, ...), please let us know how things are going in #367. Please share both positive and negative experiences you might have.

For C++ and Rust, make sure to have c++filt / rustfilt installed and available through the $PATH. Otherwise, only mangled, hard-to-decipher function names will be displayed. For Java, no additional steps are required.

Contributing

If you would like to contribute to the Bazel Visual Studio extension, please refer to the contribution guidelines for information about our patch acceptance process and setting up your development environment.

vscode-bazel's People

Contributors

allevato avatar arahatashun avatar avx-rchung avatar cameron-martin avatar cramertj avatar dependabot[bot] avatar dierksen avatar fweikert avatar gingerbear avatar hypdeb avatar iamricard avatar jblanchet-ea avatar jfirebaugh avatar kon72 avatar laurentlb avatar limdor avatar maximmalofeev avatar meteorcloudy avatar nicolasstucki avatar philwo avatar reinhillmann avatar renovate-bot avatar romannikov avatar ryanwilsonperkin avatar rynz avatar slimsag avatar smukherj1 avatar thomasvl avatar vogelsgesang avatar whilp avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

vscode-bazel's Issues

Quickpicks should use the same targets as the targets treeview

If you issue the command command pallet, the quick picks seems to query based on the whole workspace, but the tree view is rooted at the opened folder.

In the case of really large repos, that can result in the quick pick providing a lot more info and thus maybe even taking a really long time to show anything.

Is that a feature or a bug? i.e. - should the list in the quick pick be the same list as the fully expanded tree view?

Add a configuration option to filter the Bazel target tree view

Many times, BUILD files contain macros that generate targets that are purely implementation details that are meant to be hidden from the user (for example, ios_application currently produces a handful of extra targets to work around current limitations in Bazel's APIs). These targets are just noise in the tree, so we should have a config setting that lets users specify a list of rule classes (or patterns) that shouldn't be shown.

Running build target fails with fish shell

With the default shell set to fish building targets from the BAZEL BUILD TARGETS tree does not work. The && characters that are used in the terminal command cd <package directory> && bazel build <target> are not valid in the fish shell. Fish uses the syntax cd <package directory>; and bazel build <target>.

Provide a `bazel clean` command

At a minimum, the command palette should provide easy access to bazel clean, and probably a handful of other useful Bazel commands.

One edge case we'll need to handle is if the user has a multi-directory VS Code workspace that spans multiple Bazel workspaces. If that's the case, we'd need to pop up a quick pick that lets the user select which workspace they actually want to run the command in.

Breakpoints may or may not fire depending on the form of `load()` being used

This affects debugging of .bzl files that are in the same repository as the target being built.

Let's imagine we have a workspace named foo that contains bar.bzl, and we want to place a breakpoint in that file. Under Bazel's execroot, there will be a symlink foo to the actual directory where the workspace exists (let's call it $HOME/Scratch/foo), and bar.bzl will be in there as expected.

Likewise, files referenced from external repository references are under Bazel's external directory (relative to output_base). This includes "external-looking" references to the same workspace. So in our case, if we refer to @foo//:bar.bzl, then that shows up as a symlink in .../external/foo/bar.bzl that points to the original file.

The problem is, the source location that Bazel tests in the debug server to decide whether a breakpoint should fire differs depending on how the file was loaded.

For example, if I do the following:

load("@foo//:bar.bzl", ...)

Then Bazel asks "is there a breakpoint at /private/var/tmp/_bazel_allevato/<HASH>/external/foo/bar.bzl?" This is the form of breakpoint that we send to the debug server today. (The reason I implemented this one is because it just happened to work with the repository I was testing against, which references its own .bzl files using the repo name.)

However, if I do the following:

load("//:bar.bzl", ...)

Then Bazel asks "is there a breakpoint at $HOME/Scratch/foo/bar.bzl?" In this case, it appears that it's resolving the execroot/foo symlink and then looking relative to that location.

Even though these are the same file, Bazel's path comparison sees them as being different, and a breakpoint set for one won't fire for the other.

The only way I can see around this for now is for us to send two breakpoints to the server so that the breakpoint fires regardless of whether the .bzl file was loaded using a repository-qualified path or not. ๐Ÿ˜•

Bazel Build Targets doesn't list root targets

Some package, since they are likely to be used by other larger builds, have very basic BUILD files, so they only need targets at the root of their workspace. The Bazel Build Targets panel doesn't seem to be able to support/show this.

git clone --recursive https://github.com/protocolbuffers/protobuf.git and then open that folder, and you'll see you can't act on any of the targets in the side bar. Code Lens when looking at the BUILD file does work through.

Implement debug server

Once the basic UI to select and build targets goes in (#5), we'll have enough of a front-end in place that I can start moving my debugger prototype over.

Implement language server for Starlark

First off, I'm really excited to see the Bazel team creating a repository for vscode support and I would love to contribute to it!

Secondly, Is this Repository going to be developing a Language Server Protocol implementation? Seems like it could be a great opportunity to develop a resource that could be reused in other editors as well.

"Build/Test Target" only work from bazel target panel

Currently "Build/Test Target" commands only work from bazel target panel, and that panel is not very useful when there are hundreds of targets (eg. in a monolithic repo). Any attempt to run those commands from a build file or source file will result in a failure like "Running the contributed command:'bazel.buildTarget' failed."

[2018-12-27 02:23:24.051] [exthost] [error] TypeError: Cannot read property 'getBazelCommandArgs' of undefined
    at bazelBuildTarget (/Users/xiaoyi/.vscode/extensions/bazelbuild.vscode-bazel-0.0.2/out/src/extension/extension.js:41:26)
    at e._executeContributedCommand (/Applications/Visual Studio Code.app/Contents/Resources/app/out/vs/workbench/node/extensionHostProcess.js:501:455)
    at e.$executeContributedCommand (/Applications/Visual Studio Code.app/Contents/Resources/app/out/vs/workbench/node/extensionHostProcess.js:502:6)
    at t._doInvokeHandler (/Applications/Visual Studio Code.app/Contents/Resources/app/out/vs/workbench/node/extensionHostProcess.js:658:837)
    at t._invokeHandler (/Applications/Visual Studio Code.app/Contents/Resources/app/out/vs/workbench/node/extensionHostProcess.js:658:509)
    at t._receiveRequest (/Applications/Visual Studio Code.app/Contents/Resources/app/out/vs/workbench/node/extensionHostProcess.js:657:126)
    at t._receiveOneMessage (/Applications/Visual Studio Code.app/Contents/Resources/app/out/vs/workbench/node/extensionHostProcess.js:656:59)
    at /Applications/Visual Studio Code.app/Contents/Resources/app/out/vs/workbench/node/extensionHostProcess.js:653:895
    at /Applications/Visual Studio Code.app/Contents/Resources/app/out/vs/workbench/node/extensionHostProcess.js:130:793
    at e.fire (/Applications/Visual Studio Code.app/Contents/Resources/app/out/vs/workbench/node/extensionHostProcess.js:133:218)
    at a (/Applications/Visual Studio Code.app/Contents/Resources/app/out/vs/workbench/node/extensionHostProcess.js:186:147)
    at Socket.n._socketDataListener (/Applications/Visual Studio Code.app/Contents/Resources/app/out/vs/workbench/node/extensionHostProcess.js:186:368)
    at emitOne (events.js:116:13)
    at Socket.emit (events.js:211:7)
    at addChunk (_stream_readable.js:263:12)
    at readableAddChunk (_stream_readable.js:250:11)
    at Socket.Readable.push (_stream_readable.js:208:10)
    at Pipe.onread (net.js:594:20) bazel.buildTarget

I think there should be an option to run those commands directly from source code, the target could be as simple as :all or dynamically queried based on the bazel package that the focusing file belongs to (basically iterate through all the parent directories to find the build file). Which will eliminate the initial query time, and make the extension scale in a large repo.

Tree explorer view doesn't work when installed from marketplace

I made 0.0.1 available in the marketplace this morning, but when I try opening a Bazel workspace in VS Code, the Bazel Build Targets view simply shows "There is no data provider registered that can provide view data."

There doesn't seem to be anything useful in the logs, the compiled code is all present in the installed extension, and the Contributions tab shows that the package.json reports that it contributes that view, so it's almost as if the extension startup code isn't running.

The only reference I can find to this error message is a Stack Overflow post from 12 hours ago, which doesn't yet have any responses: https://stackoverflow.com/questions/53512544/error-when-extension-is-deployed-there-is-no-data-provider-registered-that-can

I'll have to dig a bit more.

command to build/test all targets in the opened directory (package)

Prior to this extension, we use custom tasks to build/test all bazel targets in the opened directory. Would like to have these commands provided by this extension.

  "options": {
    "cwd": "${fileDirname}"
  },
  "tasks": [
    {
      "label": "Bazel: build :all",
      "group": {
        "kind": "build",
      },
      "command": "bazel build :all",
    },
    {
      "label": "Bazel: test :all",
      "group": {
        "kind": "test",
      },
      "command": "bazel test :all"
    },
  ],

[Windows] "Buildifier was not found;" each time

Hi, I have noticed that vscode-bazel pop ups "Buildifier was not found;" error on each startup despite of buildifier existence.

I check it, buildifier is present within PATH and I can call it from internal console by typing buildifier

image

Another strange point is that buildifier file for windows has no extension. So, it couldn't be executed in console. I downloaded buildifier from https://github.com/bazelbuild/buildtools/releases

Could you please help me to solve this?

activation of 0.0.1 release failed

I downloaded the recent release and installed it into VS Code 1.29.1 running on Mac OS 10.13.6.

The developer tools show the following error:
Activating extension 'BazelBuild.vscode-bazel' failed: Cannot find module 'xml2js'

Reaching stdout buffer limit when implementing QuickPick suggestions for Build/Test commands

I intend this issue to be a design/future direction discussion.

I was trying to implement providing QuickPick suggestions for the commands added by this extension. I implemented a query to get all build targets for the build command and all test targets for the test command. However, when I tried to test it, I got a buffer overflow error triggered as a result of the limit set here

maxBuffer: 500 * 1024

I was testing this on the absel-cpp github repo. My query for all targets in abseil-cpp gives me 1,285,279 characters. However, this might be because query always selects "xml". If I change it to "--output label", the output is 6819 characters.

So I want to discuss ways to implement QuickPick:-

  1. Is the current buffer size 500*1024 too conservative? Should I increase it to 50 MB?
  2. Should I add support to query only "labels" instead of the full xml? This is uglier because the result of an empty query has a couple of INFO messages from bazel.
    INFO: Invocation ID: f58ebc01-f206-4ef1-a362-93d956881d19 INFO: Empty results
    I wonder if these can be turned off.
  3. Another option would be to provide an option to bazel to limit the number of targets returned in a query. I'm not sure if there's an option to do this right now but I couldn't find one. Ideally the query results should be sorted in a pre-order traversal order.
  4. Design our own WebView panel for bazel invocation and use https://code.visualstudio.com/docs/extensionAPI/vscode-api#CompletionItemProvider.provideCompletionItems

Personally I like 2 the most as it is the easiest without any memory impact. 3 might need Bazel support. 1 is by far the easiest but the question is whether we are ok with increasing the memory requirement.

gdb seems to inject the build executable, not the actual testing executable

Steps to reproduce:
Explorer -> Bazel build targets -> right click target -> build target with debugging

vs code version:
Version: 1.31.0
Commit: 7c66f58312b48ed8ca4e387ebd9ffe9605332caa
Date: 2019-02-06T08:51:24.856Z
Electron: 3.1.2
Chrome: 66.0.3359.181
Node.js: 10.2.0
V8: 6.6.346.32
OS: Linux x64 4.13.0-31-generic

vscode-bazel version: Version 0.1.0 (January 23, 2019)

Debug console output

INFO: Debugger connection successfully established.
Loading: 
Loading: 0 packages loaded
DEBUG: /home/ymd/ponyai/.sub-repos/common/third_party/bazel.bzl:5:5: Bazel version: 0.18.1
INFO: Analysed target //my:target (0 packages loaded).
INFO: Found 1 target...
[0 / 2] [-----] BazelWorkspaceStatusAction stable-status.txt
[0 / 4] [-----] BazelWorkspaceStatusAction stable-status.txt ... (2 actions, 1 running)
[1 / 4] Compiling my/source/file.cc; 4s linux-sandbox
[2 / 4] Linking my/target; 11s linux-sandbox
Target //my:target up-to-date:
  my/executable
INFO: Elapsed time: 81.721s, Critical Path: 78.27s
INFO: Build completed successfully, 3 total actions
INFO: Debug server listener thread closed; shutting down debug server and resuming all threads

my/executable is not executed.

Use BEP to get information about builds in progress

(From #17)

We should leverage Bazel's Build Event Protocol in the extension so that we can provide various UI feedback about builds the user launches, such as (just some random ideas):

  • Progress indicators
  • Scraping common error/warning patterns from command output and surfacing the information in the Problems view
  • showing the full Bazel output in a nicely formatted webview

Like the debugger, we can "vendor" the protos we need and generate the TS interfaces for them.

Bazel Target Tree view should have a refresh command

An explicit refresh button in the view's toolbar would be useful if the user makes a change in their workspace that VS Code doesn't detect as requiring a refresh. For example, we refresh on changes in BUILD files, but not for .bzl files. Even if we do decide to start refreshing based on more changes, the explicit control is a good escape hatch if the IDE doesn't catch up.

`npm outdated`: Unpin/updated some deps?

Current setup seems to have a few things listed:

npm outdated -

Package               Current  Wanted   Latest  Location
@types/node            6.14.2  6.14.4  11.13.4  vscode-bazel
tslint                 5.11.0  5.15.0   5.15.0  vscode-bazel
typescript              3.1.6   3.4.3    3.4.3  vscode-bazel
vscode-debugadapter    1.32.1  1.34.0   1.34.0  vscode-bazel
vscode-debugprotocol   1.32.0  1.34.0   1.34.0  vscode-bazel

List of targets never loads

I am working in a fairly complex workspace, with many targets, external workspaces, etc. The list of targets never loads, and the extension host process is pegged at 100% CPU.

Version: 1.31.1
Commit: 1b8e8302e405050205e69b59abb3559592bb9e60
Date: 2019-02-12T02:19:29.629Z
Electron: 3.1.2
Chrome: 66.0.3359.181
Node.js: 10.2.0
V8: 6.6.346.32
OS: Linux x64 4.19.16-1rodete1-amd64

Using version 0.1.0.

Interferes with ibazel

Using the vscode plugin, every time a file is saved it seems to do same bazel query calls to the local bazel server.

If you're also running a watch mode at the same time, it takes a long time to get a result in the ibazel session because the server is locked:

Build graph changed: "/usr/local/google/home/alexeagle/Projects/angular-bazel-example/src/lib/shorten/BUILD.bazel". Requerying...
Querying for files to watch...
Starting local Bazel server and connecting to it...
Loading: 0 packages loaded
Loading: 9 packages loaded
    currently loading: @build_bazel_rules_nodejs//internal/web_package ... (12 packages)
Loading: 375 packages loaded

Loading: 375 packages loaded
Another command holds the client lock: 
pid=147569
owner=client
cwd=/usr/local/google/home/alexeagle/Projects/angular-bazel-example

Waiting for it to complete...
Another command holds the client lock: 
pid=147575
owner=client
cwd=/usr/local/google/home/alexeagle/Projects/angular-bazel-example

Waiting for it to complete...
Starting local Bazel server and connecting to it...
Loading: 0 packages loaded
Loading: 0 packages loaded
Loading: 375 packages loaded

Loading: 375 packages loaded
Runing //src:devserver
Notifying of changes
Loading: 
Loading: 0 packages loaded
Analyzing: target //src:devserver (0 packages loaded, 0 targets configured)
Analyzing: target //src:devserver (5 packages loaded, 26419 targets configured)
INFO: Analysed target //src:devserver (5 packages loaded, 26424 targets configured).
INFO: Found 1 target...
[0 / 3] [-----] BazelWorkspaceStatusAction stable-status.txt
[27 / 40] checking cached actions
[43 / 48] Compiling TypeScript (devmode) //src/lib/shorten:shorten; 0s worker
[45 / 48] Compiling Angular templates (ngc) //src/app/hello-world:hello-world; 0s worker
[45 / 48] Compiling Angular templates (ngc) //src/app/hello-world:hello-world; 1s worker
[46 / 48] Compiling Angular templates (ngc) //src/app:app; 0s worker
Target //src:devserver up-to-date:
  dist/bin/src/devserver_launcher.sh
  dist/bin/src/devserver
INFO: Elapsed time: 10.939s, Critical Path: 6.00s
INFO: 4 processes: 4 worker.
INFO: Build completed successfully, 9 total actions
INFO: Build completed successfully, 9 total actions
SUCCESS
Error writing success to stdin: write |1: broken pipe
Triggering live reload
requesting reload: reload

somehow these two need to play nicely together

Document how one can obtain and install this extension

Hi,
I'd really like to use this :)
From the readme it's not clear how one should do this. I tried cloning the repo, building it with npm but then got stuck on installing vsce which I read is how I'm supposed to install manually built extensions.
If I'm on the right path I think documenting it will be super helpful. If I'm not then even more :)

Thanks for all your work...

Add Uri schemes to document selectors

The debug console when running our extension shows messages like these at activation time:

[UriError]: Scheme is missing: {scheme: "", authority: "", path: "", query: "", fragment: ""}
extensionHostProcess.js:76
Extension 'BazelBuild.vscode-bazel' uses a document selector without scheme. Learn more about this: https://go.microsoft.com/fwlink/?linkid=872305
extensionHostProcess.js:732

According to https://go.microsoft.com/fwlink/?linkid=872305, we should be explicit about the file scheme for our document selectors to ensure that we can safely use the vscode.Uri.fsPath property to find the file (because it could be a remote file, or not saved yet).

Error when "Build Target (with Debugging)" commands are invoked from command palette

The commands work from the tree view (because they are passed the arguments they need) but if invoked from the command palette, they don't have an argument and they error out.

According to microsoft/vscode#45119, that's expected and we need to handle the case of the command being invoked in a different context. In our case, we should detect whether there's no argument and pop up an alternative UI, like a quick-pick list to let the user type/select the target name.

Build //:target overlay in BUILD fail going out of screen

I have a macro that creates a lot of targets and they end up going outside the screen, see:

image

To be fair we can probably could make the macro a bit cleaner to not expose as many targets and it is not a big issues I just wonder if anything can be done about this situation.

Investigate using `--output=proto` for Bazel queries

(From #17)

Now that we depend on protobufjs for the debugger protocol, we should consider using protos for queries instead of the XML output. It's significantly less data to process and we get nicely typed values for free.

We can "vendor" the build.proto file the same way we already do for the debugger protocol and generate types from that.

Use tasks for build/test actions

For expediency to get the debugging up and running, I've implemented commands that just launch Bazel directly to perform build/test runs. We should look into using the tasks APIs for these.

Buildifier lint fails

When opening a file that has lint issues, I see that in the developer console:

ERR Command failed: buildifier --type=bzl --lint=warn
<stdin>:3: load: Loaded symbol "rust_binary" is unused. Please remove it.
To disable the warning, add '@unused' in a comment. (https://github.com/bazelbuild/buildtools/blob/master/WARNINGS.md#load)
<stdin>:4: load: Loaded symbol "rust_library" is unused. Please remove it.
To disable the warning, add '@unused' in a comment. (https://github.com/bazelbuild/buildtools/blob/master/WARNINGS.md#load)
<stdin>:5: load: Loaded symbol "rust_test" is unused. Please remove it.
To disable the warning, add '@unused' in a comment. (https://github.com/bazelbuild/buildtools/blob/master/WARNINGS.md#load)
: Error: Command failed: buildifier --type=bzl --lint=warn
<stdin>:3: load: Loaded symbol "rust_binary" is unused. Please remove it.
To disable the warning, add '@unused' in a comment. (https://github.com/bazelbuild/buildtools/blob/master/WARNINGS.md#load)
<stdin>:4: load: Loaded symbol "rust_library" is unused. Please remove it.
To disable the warning, add '@unused' in a comment. (https://github.com/bazelbuild/buildtools/blob/master/WARNINGS.md#load)
<stdin>:5: load: Loaded symbol "rust_test" is unused. Please remove it.
To disable the warning, add '@unused' in a comment. (https://github.com/bazelbuild/buildtools/blob/master/WARNINGS.md#load)

	at ChildProcess.exithandler (child_process.js:287:12)
	at emitTwo (events.js:126:13)
	at ChildProcess.emit (events.js:214:7)
	at maybeClose (internal/child_process.js:925:16)
	at Process.__dirname.ChildProcess._handle.onexit (internal/child_process.js:209:5)

I suspect it breaks due to bazelbuild/buildtools#470
It's expected normal that Buildifier exits a non-zero code in that case.

getDefaultBazelExecutablePath() returns empty string

I have an empty setting for bazel.executable and the build task failed due to "build: command not found". After manually set bazel.executable to "bazel", build task works. I believe that getDefaultBazelExecutablePath() returns an empty string for some reason (though the code looks sane to me).

Please consider setting "bazel" as the default for bazel.executable or using WorkspaceConfiguration.get<T>(section: string, defaultValue: T) instead.

This is also the case for bazel.buildifierExecutable.

image

image

Add buildifier support

Even in the absence of a full language server (#1), we should add support for buildifier to surface lint warnings in the editor and support --fix mode as a formatting action.

"Unable to open" on Windows

Using the plugin on Windows, any item I click on in the 'BAZEL BUILD TARGETS' list shows an error dialog:

image

In this case, I'm working on my D drive.

Migrate to buildifier JSON output

JSON output is being added to buildifier in bazelbuild/buildtools#612. This will be much easier for us to parse, and it also gives us more fine-grained diagnostic information (the start and end line/column locations) so we can produce better diagnostic decorations.

Syntax highlighting in BUILD files

I don't get syntax highlighting only in BUILD files (language mode defaults to "Plain text").
If I rename my file to BUILD.bazel, the syntax highlighting turns on.

Build all targets inside a package

ATM, all targets are being loaded in the view (Bazel build targets). Every time i want to run all the targets inside a package i have to write the 1 liner for loop in bash to build all targets read from $(bazel query //...). It would be good option to add to this view.

Extension causes high cpu load

  • Issue Type: Performance
  • Extension Name: vscode-bazel
  • Extension Version: 0.1.0
  • OS Version: Linux x64 4.13.0-32-generic
  • VSCode version: 1.33.1

Find more details here: https://github.com/Microsoft/vscode/wiki/Explain:-extension-causes-high-cpu-load

Hi, I see there is a related issue #104 which might have been fixed in #89 (log file attached). Is there a way to quickly apply it to my workspace aside from waiting for a new release?

BazelBuild.vscode-bazel-unresponsive.cpuprofile.txt

Add node_modules/@bazel/buildifier to search locations

Frontend developers typically won't install Buildifier on their system path. Instead it will be fetched along with their other toolchain dependencies by a package manager like npm or yarn

Opening a frontend project in VSCode results in a warning from the bazel plugin because buildifier isn't on the $PATH

It would be nice to look in $workspace/node_modules/@bazel/buildifier-${platform} to find the binary. Or, it could execute $workspace/node_modules/@bazel/buildifier/buildifier.js which has a shebang line to execute in nodejs and will spawn the platform-specific binary.

vscode-bazel hangs: "took a very long time to complete its last operation"

vscode is reporting in the status that:
The extension 'vscode-bazel' took a very long time to complete its last operation and it has prevented other extensions from running.
Looking at the running extensions and it shows 20ms activation and a Profile of over 5000ms.

In addition it seems that all of the plugin features are not working. For example, I'm not seeing any build targets. It is also prevent my other plugins from working.

Any way I can go about debugging this? Right now I have to keep the plugin disabled.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.