Extensions startup loading order

[muuvmuuv]

There has been an issue here without a potential solution: #13292

I don't want to give extensions the power to set their priority of loading in my VSCode I rather want myself setting a priority to some extensions I want to have loaded before the others.

For example, I have an extension that shows me saved projects (Project Manager) and I want this to be loaded at first to fast select a project before the rest is loaded because when I have selected a project the viewport will be reloaded anyway.

My solution, having a option like this:

"workbench.extensions.loadingOrder": {
    "alefragnani.project-manager": {
      "priority": 10000
    }
  },

all other extensions would be loaded as before after these prioritised extensions.

[keelzebub]

This feature would be amazing. My use case is the exact same - I'd love the ability to set Project Manager as the first extension loaded, so I can get to work right away while other extensions are still processing.

[ackphill]

I need same feature with different reason. I'm using vim extension and whenever I run vscode, I have to wait until vim extension being loaded before I start editing. It's quite annoying.

[Taoquitok]

Commenting on this for the same reason as others, Being able to bump Project Manager to load ahead of other extensions would be a lovely way of getting to pick a project quicker.
Even with disabling most extensions within the default load, there's enough of a slow down ahead of seeing project manager load to make me sigh each time.

[alefragnani]

I‘ll take a look if there is something that can be changed to make VS Code prioritize the extension.

I didn’t look at VS Code source code yet, but maybe the excess of activationEvents may be moving it to the end. Maybe the kind of activationEvents. Maybe alphabetic reasons 😆

Let’s see what I can find.

[ashkitten]

my issue is slightly different - i use direnv's nix integration to import project-specific dependencies into the shell environment when i cd into the project dir. however, even though i can create an extension to load the direnv environment in vscode, other extensions such as rls-vscode may still load before the environment is loaded, causing them to not work since the binary is not in the path yet. simply put, i need a way to delay the startup of other extensions until mine is loaded.

[miloslavnosek]

My use case would be to be able to specify which extensions take precedence over others when multiple extensions change same features.

For instance if I install IntelliJ keybinds and Vim, IntelliJ keybinds will override some of Vim's hotkeys and I'd prefer it to be the other way around so that Vim overrides the keybinds extension hotkeys.

[Rizary]

@ashkitten did you manage to solved your use case? I've been looking for the solution and come to this thread. And by looking at your comment, I have same case when I want to load direnv extension before other extensions.

[ashkitten]

no. i haven't been able to use vscode for my workflow because of this issue so i just use neovim still. bit of a shame.

[anka-213]

@Rizary I've been using the extension nix environment selector with some success. It does however force you to reload VS code whenever the environment changes.

[Rizary]

@Rizary I've been using the extension nix environment selector with some success. It does however force you to reload VS code whenever the environment changes.

I'm using flake and I've try that extension without success. I'm in WSL2 too, and using rust-analyzer. I've tried with Haskell-language-server extension, it works after several retry. So maybe rust-analyzer didn't do retry as haskell-language server did

[JosXa]

I need same feature with different reason. I'm using vim extension and whenever I run vscode, I have to wait until vim extension being loaded before I start editing. It's quite annoying.

It is not just annoying, it completely disrupts your workflow because if the vim plugin is installed, not even regular input is available.

Let me demonstrate:

Here, I am constantly pressing keys when in the focused editor.
https://user-images.githubusercontent.com/7313176/103057293-5f8b1880-459f-11eb-96c0-b27d5259d95c.mp4

I mean, I am used to IDEs being sort of unresponsive while they're loading dependencies, but being completely unable to type anything is another level. Worse, the extension is buffering up inputs that will eventually be inserted at wherever the cursor happens to be at a later moment, which makes me launch vscode windows and then go and grab a cup of coffee. It has been frustrating me since I started using vscode around two years ago.

This seems to be the case for all of the "grab-all-your-inputs" kinds of extensions (i.e. the Vim ones)

Optimizing my extensions somewhat helps, but as soon as one slows down or encounters lots of exceptions due to an update, I'm back to waiting for the extension to be loaded.

Are others not experiencing this, as the thread seems kind of empty..? Maybe I'm missing a related issue, if so please let me know :)

[alefragnani]

@JosXa I'm not saying it is the solution for you, or anyone where where the startup time is an issue, but did you check the Developer: Startup Performance report VS Code can generate?

I didn't dig on how to correctly evaluate the report, and the only docs I found is https://github.com/Microsoft/vscode/wiki/Performance-Issues. But maybe it could help VS Code team and even the Vim extension team see if something can be improved .

[JosXa]

@JosXa I'm not saying it is the solution for you, or anyone where where the startup time is an issue, but did you check the Developer: Startup Performance report VS Code can generate?

I didn't dig on how to correctly evaluate the report, and the only docs I found is https://github.com/Microsoft/vscode/wiki/Performance-Issues. But maybe it could help VS Code team and even the Vim extension team see if something can be improved .

Hi @alefragnani, yes - it's super useful! But still takes a long time when only the extensions I consider absolute essentials are being loaded (even have a custom extension pack).

It's bearable, but as I said - as soon as an extension gets broken by autoupdate vim might be delayed again. It's strange

[PellegattaSimone]

Has anybody found a solution?

[Dimfred]

This is why I am thinking of switching to neovim. That really bugs me. Would be great to have a fix for that.

[impl]

@ashkitten, @Rizary,

I had the same issue as you. If you're comfortable with defining all of your extensions in Nix, e.g. using Home Manager, you can hack around this like so:

{
  programs.vscode = {
    enable = true;
    package = pkgs.vscode.overrideAttrs (old: {
      buildInputs = old.buildInputs or [] ++ [ pkgs.makeWrapper ];
      postInstall = old.postInstall or [] ++ [ ''
        wrapProgram $out/bin/code --add-flags '--force-disable-user-env'
      '' ];
    });
    extensions = let
      loadAfter = deps: pkg: pkg.overrideAttrs (old: {
        nativeBuildInputs = old.nativeBuildInputs or [] ++ [ pkgs.jq pkgs.moreutils ];

        preInstall = old.preInstall or [] ++ [ ''
          jq '.extensionDependencies |= . + $deps' \
            --argjson deps ${escapeShellArg (builtins.toJSON deps)} \
            package.json | sponge package.json
        '' ];
      });
    in
      pkgs.vscode-utils.extensionsFromVscodeMarketplace [
        {
          publisher = "cab404";
          name = "vscode-direnv";
          version = "1.0.0";
          sha256 = "sha256-+nLH+T9v6TQCqKZw6HPN/ZevQ65FVm2SAo2V9RecM3Y=";
        }
      ] ++ map (loadAfter [ "cab404.vscode-direnv" ]) (
        with pkgs.vscode-extensions; [
          bbenoist.nix
          editorconfig.editorconfig
          golang.go
        ] ++ pkgs.vscode-utils.extensionsFromVscodeMarketplace [
          {
            publisher = "mrded";
            name = "railscasts";
            version = "0.0.4";
            sha256 = "sha256-vjfoeRW+rmYlzSuEbYJqg41r03zSfbfuNCfAhHYyjDc=";
          }
        ]
      );
  };
}

This modifies all the extension packages to depend on the direnv extension using extensionDependencies. (Not sure if the force-disable-user-env wrapper is required or not. Feel free to try without.) All in all, not great, but it gets the job done...

[muuvmuuv]

I do still believe this can get things up quicker and also reduce flickering for highlighting in code like with lately released typescript features but I am on a Apple Silicon now and its just that fast I do not need to disable and extension anymore its just up and running in a second. Still in a future with more and more fratures coming into code and more plugins beeing heavy lifters it will be required to have something like a loading order or manual delay

[sisrfeng]

I need same feature with different reason. I'm using vim extension and whenever I run vscode, I have to wait until vim extension being loaded before I start editing. It's quite annoying.

Sometimes I make my code dirty by accident because of this

[offlinehacker]

I have implemented a workaround for vscode remote containers, where dependencies (on specific other extension) are injected on the fly while extensions are being installed. It's ugly, but it works https://github.com/xtruder/nix-devcontainer/tree/main/src/ext-preloader. Having extension priorities or at least a way how to make extension to load before other extensions, would make life so much easier.

[milahu]

nix workaround with nix-env

useful for unprivileged users (if you have no root access to the remote machine)

# pkgs.nix
/*
based on
https://discourse.nixos.org/t/how-can-i-set-up-my-rust-programming-environment/4501/9
*/
let
  rust_overlay = import (builtins.fetchTarball "https://github.com/oxalica/rust-overlay/archive/master.tar.gz");
  pkgs = import <nixpkgs> { overlays = [ rust_overlay ]; };
  rustVersion = "latest";
  #rustVersion = "1.64.0";
  rust = pkgs.rust-bin.stable.${rustVersion}.default.override {
    extensions = [
      "rust-src" # for rust-analyzer
    ];
  };
in
{
  inherit rust;
  inherit (pkgs) rust-analyzer cargo-watch;
}

nix-env -q # list installed packagaes
nix-env -e '.*' # uninstall all packages from nix-env

# install rust toolchain
nix-env -f ./pkgs.nix -i -A rust
nix-env -f ./pkgs.nix -i -A rust-analyzer
nix-env -f ./pkgs.nix -i -A cargo-watch
cargo --version; rustc --version # check versions
nix-env -q # list installed packagaes

# install more tools ...
nix-env -f '<nixpkgs>' -i -A jq
nix-env -f '<nixpkgs>' -i -A screen
nix-env -f '<nixpkgs>' -i -A gcc
nix-env -f '<nixpkgs>' -i -A gnumake
nix-env -f '<nixpkgs>' -i -A python3
nix-env -f '<nixpkgs>' -i -A nodejs-16_x # for vscode-server

nix-env -e screen # uninstall some package

im sure there are prettier ways to do this, but this works ...

[vscodenpa]

We closed this issue because we don't plan to address it in the foreseeable future. If you disagree and feel that this issue is crucial: we are happy to listen and to reconsider.

If you wonder what we are up to, please see our roadmap and issue reporting guidelines.

Thanks for your understanding, and happy coding!

[anka-213]

@isidorn This indeed a crucial feature for several use cases as many people have already expressed in this thread. Several of the cases have no known workaround

[milahu]

ideally add a process supervisor like systemd to vscode ...

• https://github.com/Unitech/PM2
• https://github.com/wikimedia/service-runner

similar issue: #54775 - manage multiple processes while debugging

[The-Compiler]

I'm also a bit confused by the guidelines linked above - they say (emphasis mine):

Here are the criteria we use to make the decision about closing a feature request:

1. [...]
2. Has the community at large expressed interest in this functionality? I.e. has it gathered more than 20 up-votes or more than 20 comments? This criterion alone covers more than 650 of the 2850 open feature requests as of right now, October 9th, 2019.
3. [...]

If the answer to any of the three questions is yes then we ask about affordability:

4. Can our team afford to implement the feature? I.e. are the costs to implement the functionality reasonable compared to the size of our team?

In summary, a feature needs to pass one of 1-3 and 4. Otherwise, we'll close it as out of scope. We'll unsubscribe from these issues to reduce the overall number of issue notifications we receive every day.

Clearly 2. is true (49 upvotes, 20 comments at the time this was closed). Thus, this would imply that the costs of implementing this are unreasonable compared to the size of the VS Code team?

I find this hard to believe. I'm well aware of the trap of saying something "must be easy" without actually putting in the work (or knowing the codebase). However, even a simple solution (like having a list of extension names in the config being loaded before the rest) seems like it would help with a lot of use-cases people have mentioned here - including mine, using extensions like Vim or VSpaceCode and wanting them to be responsible as early as possible after starting VS Code.

[crxyz0]

Any updates? I have the same VSCodeVim issue and would really like this feature. My computer isn't that fast and it takes ~5 seconds before Vim loads and I can actually edit the file.

[zimbatm]

I believe this issue impacts many users, but they don't know that the root cause is the extension loading order issue. From their perspective, VSCode is just unstable. Sometimes it works, sometimes they have to restart the editor.