Tracking: harmful `jq`/`sponge` for VS Code extensions

It is good for Nixpkgs to provide the binaries that VS Code extensions require in order to operate properly. However, this must be done carefully. It is common for an extension to have a hierarchy of places where it looks for the binary, so we must not disrupt the ordering of that hierarchy. Here's a common way that can happen: - Let's say there's a VS Code extension named `foo.bar`. - It has a setting named `foobar.languageServerPath` which defaults to `null`. - When the setting is `null`, the extension looks for the binary on `PATH`. - A user has projects A and B, which depend on versions 1 and 2 of the language server respectively. - Project A has a Nix dev shell providing version 1, and project B has a Nix dev shell providing version 2. - The user provides the Nix dev shell `PATH` to their VS Code extensions via [`mkhl.direnv`](https://marketplace.visualstudio.com/items?itemName=mkhl.direnv). - Thus, if the user gets the extension directly from the VS Code Marketplace, it works correctly in both of their projects. - However, Nixpkgs modifies the extension's `package.json` so that `foobar.languageServerPath` defaults to a path in `/nix/store`. - Nixpkgs provides version 3 of the language server. - So, if the user gets the extension from Nixpkgs, it does not look at their dev shell's `PATH` and is incompatible with both project A and project B. This is a tracking issue to remove instances of that pattern. ## Buggy The packages for these extensions use `jq`/`sponge` in a way that does not achieve what the author intended. - [ ] `biomejs.biome` - [ ] `hashicorp.terraform` @rhoriguchi - [ ] `jebbs.plantuml` - [ ] `release-candidate.vscode-scheme-repl` - [ ] `tsyesika.guile-scheme-enhanced` - [ ] `zxh404.vscode-proto3` ## Harmful The packages for these extensions use `jq`/`sponge` to modify `package.json` in a way that harms the user. Typically this means that a setting's default value which would be amenable to project-local config (e.g. `PATH` or `rustup which` or `node_modules/.bin`) is replaced with a hardcoded path blocking individual projects from providing the binary. - [ ] `b4dm4n.vscode-nixpkgs-fmt` - [ ] `chrischinchilla.vscode-pandoc` #549024 - [x] `dbaeumer.vscode-eslint` #429351 - [x] `esbenp.prettier-vscode` #429239 - [ ] `eugleo.magic-racket` - [ ] `kamadorueda.alejandra` @kamadorueda - [ ] `kddejong.vscode-cfn-lint` - [ ] `mads-hartmann.bash-ide-vscode` @kamadorueda - [ ] `mkhl.direnv` - [ ] `mkhl.shfmt` #549057 - [x] `ms-python.mypy-type-checker` #380338 - [ ] `myriad-dreamin.tinymist` - [ ] `oxc.oxc-vscode` @drupol - [ ] `prince781.vala` - [ ] `reditorsupport.r` #549025 - [ ] `rust-lang.rust-analyzer` - [ ] `tecosaur.latex-utilities` @JeanCASPAR - [ ] `timonwong.shellcheck` - [ ] `ufo5260987423.magic-scheme` - [x] `vadimcn.vscode-lldb` #101179 ## Benign These packages don't need to be changed: they use `jq`/`sponge` to modify `package.json` in a way that does not harm the user. These are usually cases where the only fallback is a binary bundled in the VSIX that wouldn't work anyway (e.g. non-NixOS ELF or wrong architecture), and there is no `PATH` or toolchain discovery. - `azdavis.millet` - `betterthantomorrow.calva` - `elijah-potter.harper` - `foxundermoon.shell-format` - `gruntfuggly.todo-tree` - `jackmacwindows.craftos-pc` - `oliver-ni.scheme-fmt` - `tekumara.typos-vscode` - `valentjn.vscode-ltex` - `wgsl-analyzer.wgsl-analyzer` - `yzane.markdown-pdf` --- (The initial triage/categorization for this issue was done at commit 22e5fbfa4806c4fc54fa5799089692c3cfc75f33 with the help of Claude Opus 5.)