Arch Linux User Repository

For minimal changes, this package is based on https://www.archlinux.org/packages/community/x86_64/code/ . There is no plan on adding further changes/features except transparent window support.

About building, currently code 1.47.3-1 uses nodejs-lts-dubnium (Node 10.x) as a makedep. It will conflict with your already installed nodejs (latest version of Node) package, usually installing with AUR helpers or directly running makepkg.

Here are two recommended solutions:

Solution A:

Build this package in a clean environment with Arch Linux devtools (https://wiki.archlinux.org/index.php/DeveloperWiki:Building_in_a_clean_chroot#Convenience_way) to build the package.

extra-x86_64-build (comes from devtools) will build the package in a clean environment, without bothering your local packages.

Solution B:

Use archlinuxcn repo (https://github.com/archlinuxcn/repo).

Frantic1048 added code-transparent to archlinuxcn repo, which follows updating of this AUR package. You can install code-transparent with the prebuilt package from archlinuxcn repo.

@frantic1048 Yes this works! thank you for updating to 1.51 and applying this patch!

@jaap: I just made a small patch similar to your link to workaround the first window issue in 1.51.1-1 version. I've tested the patch on my machines and it works fine.

You can take a try with archlinuxcn/code-transparent (packaged by frantic1048) or this AUR package, to see if the first window issue is gone.

The changes can be seen here: https://aur.archlinux.org/cgit/aur.git/commit/?h=code-transparent&id=c5860490b3f436e97f0d30ae6b4e65083af3d179

Also here(managed with aurpublish): https://github.com/frantic1048/pkgbuilds/commit/8a1dabd18cb221aab677e2bac86e43ca04718fb8

@frantic, I didn't see you already commented and I don't think you'll read my edit.

Yeah the issue is that electron calls "ready" when it isn't ready yet. This is the bug: https://github.com/electron/electron/issues/16809. I had some trouble with where to place the sleep/timeout. At some point I got it to work by adding the sleep in the unit tests.

@jaap: Haha, that's really a weird workaround(the issue itself is also weird though). I will try to add that patch into this package later after testing. Thank you so much for reminding me about this workaround that I never thought about.

Can you make a patch something similar to https://github.com/JAicewizard/vscode/commit/1fff71db2204f494b99482c44155b12508c42b5b? I didnt actually test this patch on the linked repo, I tested that it works on this aur package. You can set the sleep lower but it increases the chance that it wont work.

edit: for clarity, this fix is based on https://github.com/electron/electron/issues/16809

@Kandelborg I was posting some general instructions to pin since I found many users being confused about building.

I am talking about the monthly VS Code updates. As of right now, there's a new version 1.47.x and this package still isn't updated to use it.

It should have been updated, for now. I know upstream VS Code updates frequently, so do as community/code package. I'm not updating the package immediately after community/code update because I have to check if the transparency patch is still working in the new version.

The transparent feature is not an officially supported feature (It is not enabled by just a build-time feature flag, but a real patch to source code, and the patch itself is also maintained by me). There were awesome guys implement this feature, but sadly, being rejected by the Code team after opening a PR over a year( Long story here: https://github.com/Microsoft/vscode/pull/52707 )

It is necessary to test before updating the new version because upstream changes could break the patch (code conflict, or the transparent feature being broken). This happens several times during the days I was maintaining aur/atom-transparent.

Anyway, testing is not that time-consuming work and update could be quicker, I'm sorry for it. BTW I'm using code-transparent from day to night every day.

Furthermore, the package is perfectly buildable with Node >= 10.x <= 12.x not just one node lts version e.g dubnium. I have tried building with node 12.x by following the official build guide it worked without problems. The official build guide says it's possible within the range i disclosed before.

This package follows community/code's config, and of course the node version. It is working and I do not found much gaining maintaining a derived PKGBUILD from community/code with a different toolchain.

Instead of having to edit the PKGBUILD in order to get the latest version of VS Code, would you be so kind as to maintain the package and update the version numbers? This has nothing to do with node version or anything else, simply keeping the package updated.

As mentioned above, I'd do my best to keep this package up to date :)

On a side-note; VS Code reverted the use of Electron 9 in the latest version bump, they are going to upgrade soon, and in fact, was already upgraded. This package should be updated to use the correct version of electron at that point.

This is the same issue with node version, community/code is using electron7 package for code 1.47.3-1. If a change to electron version is need(as required by upstream) and it is working, community/code would update electron version first, and possibly create a separate electron package for the new code with the new electron version.

E.g. electron 9, in your case, there could be a new electron9 package for code(just like current electron7 package), because official repo does not have separate electron 9 for now.

I am talking about the monthly VS Code updates. As of right now, there's a new version 1.47.x and this package still isn't updated to use it.

Furthermore, the package is perfectly buildable with Node >= 10.x <= 12.x not just one node lts version e.g dubnium. I have tried building with node 12.x by following the official build guide it worked without problems. The official build guide says it's possible within the range i disclosed before.

Instead of having to edit the PKGBUILD in order to get the latest version of VS Code, would you be so kind as to maintain the package and update the version numbers? This has nothing to do with node version or anything else, simply keeping the package updated.

On a side-note; VS Code reverted the use of Electron 9 in the latest version bump, they are going to upgrade soon, and in fact, was already upgraded. This package should be updated to use the correct version of electron at that point.

For minimal changes, this package is based on https://www.archlinux.org/packages/community/x86_64/code/ . There is no plan on adding further changes/features except transparent window support.

About building, currently code 1.47.3-1 uses nodejs-lts-dubnium (Node 10.x) as a makedep. It will conflict with your already installed nodejs (latest version of Node) package, usually installing with AUR helpers or directly running makepkg.

Here are two recommended solutions:

Solution A:

Build this package in a clean environment with Arch Linux devtools (https://wiki.archlinux.org/index.php/DeveloperWiki:Building_in_a_clean_chroot#Convenience_way) to build the package.

extra-x86_64-build (comes from devtools) will build the package in a clean environment, without bothering your local packages.

Solution B:

Use archlinuxcn repo (https://github.com/archlinuxcn/repo).

Frantic1048 added code-transparent to archlinuxcn repo, which follows updating of this AUR package. You can install code-transparent with the prebuilt package from archlinuxcn repo.

@frantic1048 Are you going to maintain this package? There will be updates each month.

It would be great if we didn't have to download a complete version of node to compile. I am e.g. using NVM to manage my node versions.

VS Code also isn't relying on that specific version of node, it's a range of versions: Node.JS, x64, version >= 10.x, <= 12.x -> https://github.com/microsoft/vscode/wiki/How-to-Contribute#prerequisites

I also think this package should give a warning somewhere that there's problems saving files with sudo.