Package Details: visual-studio-code-bin 1.29.1-2

Git Clone URL: (read-only)
Package Base: visual-studio-code-bin
Description: Visual Studio Code (vscode): Editor for building and debugging modern web and cloud applications (official binary version)
Upstream URL:
Licenses: custom: commercial
Conflicts: code
Provides: code
Submitter: dcelasun
Maintainer: dcelasun
Last Packager: dcelasun
Votes: 770
Popularity: 28.097390
First Submitted: 2017-12-18 19:14
Last Updated: 2018-12-03 18:43

Pinned Comments

dcelasun commented on 2017-11-15 06:20

FREQUENTLY ASKED QUESTIONS (read before flagging or commenting!)

  • There is a new version out, why is the package not updated?

Please check this page before flagging as out-of-date. If there is no new version on that page, it's not yet released. A tag on Github is NOT a release! If you can see the new version on the updates page but the AUR package is still not updated, flag it and give it time. It's usually done within a day or two.

  • Why is $X a dependency? I don't like it.

Just because $X is not required to open the app, doesn't mean there is nothing that depends on it. Always search the comment history on AUR to see if that dependency has been previously discussed before writing your own comment. Still nothing? Then use namcap to make sure it's really not needed. If namcap doesn't complain, please leave a comment here and I'll investigate.

  • Something is broken with the app, where do I report it?

The problem might be a packaging issue (wrong paths, dependencies, icons etc), so please write a comment here first. If you don't get a reply, or if someone says it's an upstream issue, you can report it on Github.

  • I have a problem with the package or the program itself, can I email you?

No. You won't get a reply. Leave a comment here instead and be patient.

  • What happened to visual-studio-code?

It got renamed with a -bin suffix. If you have the original package installed, you will be prompted to delete it when you install this package for the first time.

Latest Comments

1 2 3 4 5 6 ... Next › Last »

matfantinel commented on 2018-12-08 19:28

I'm on Manjaro Deepin, and VS Code cannot access my system-wide $PATH variable. I am not being able to properly debug .net core apps because of that.

On VS Code, "echo $PATH" prints:


Which seems to be a default configuration, but doesn't update if I set $PATH outside of it. If I set the variable inside VS Code Terminal, it will reset after restart.

I've noticed this behavior in the Flatpak version of VS Code in Linux Mint once. In that case, installing from the website worked.

shastry commented on 2018-11-28 05:37

For delete to trash to work, this environment variable needs to be set: ELECTRON_TRASH=gio

(or trash-cli, kioclient5, kioclient)

zetxx commented on 2018-11-27 09:01

there is new code version build specially for the flatmap-stream

ckolos commented on 2018-11-26 22:57

version 1.29.1 uses/installs flatmap-stream 0.1.1 for the references-view extension.

If you have installed this package, you should read over and determine if you are affected or not.

dcelasun commented on 2018-11-03 19:34

All right, thanks for voicing your opinions everyone. I've decided to remove pylint as an optdepend in the next version. I also won't be adding any language specific dependencies from now on.

jakebailey commented on 2018-11-03 19:25

IMO, pylint is an optional dependency for an extension you can install, not for the editor itself, so it probably shouldn't be an optdepend. Optional dependencies for things like trash support definitely make sense because it's an optional editor feature, but I can think of a number of other extensions that also ask for things to be installed (the Go extension prompts to install linters, C/C++ extension asks about clang-format, etc), and I wouldn't personally want those added as optdepends either. If you configure the extension to specify a different linter (flake8/pep8), then it'll show the same prompt but for that other tool too, pylint's just the default. Always running pylint is going to stop being the default in the python extension anyway [1] [2].



(Disclaimer, I work on the python team at Microsoft, but this isn't any sort of official opinion or anything. I just noticed the added dep during an update on my personal machine.)

Anty0 commented on 2018-10-30 16:31

And of course all of this is just my opinion, so feel free to change my mind, if you know something I don't. :)

Anty0 commented on 2018-10-30 16:27

*But only packages, that can be used by that package without any plugins. (= If visual studio code does not support python without additional plugin, python-pylint should not be added as optdependcy, but if visual studio code support python by default and opening python file shows that warning without installing additional plugin, we should add python-pylint as optdependcy.)

Anty0 commented on 2018-10-30 16:20

@elgs I think, that optdepends are not about what you want, but about what you may want. So they should contain packages, that can be for someone only "pollution".

Personally, I think, that in optdepends should be every package, which can be used by that package in any way. Also sometimes it is good idea to add as optdependcy package, that is not used by that package, but can make usage of that package significantly easier. (There are lot of examples of that in official Arch Linux packages.)

elgs commented on 2018-10-30 03:47

Personally, I don't mind if there is a ton of optdepends.

I know you don't mind. But other people may see it as pollution. Many people don't like anything which is not necessary for them.