[{"type":"blog","content":"\r\n![svelte_inspector](https://github.com/Theo-Steiner/theosteiner.de/assets/40017636/5fe2b7ff-e100-40dd-a3c4-cfbc98376b74)\r\nLet's say you're doing some web development and you notice that one button you haven't touched in years has a slight contrast issue. Searching for the relevant component could literally cost you seconds and just thinking about searching for it in your codebase gives you major anxiety?\r\nWhat if I told you, you can just click the element in question, and just like that, your editor opens at the correct position, you finish your daily tasks with never before seen agility and finally get that promotion you deserve?\r\n\r\nI know, I know… clicking things and using neovim goes together like bleach and acid cleaner. But hear me out on this one, because it is going to blow your mind - hopefully in a more pleasant way than inhaling the chlorine gas produced from incorrectly cleaning your toilet would! 🤯 \r\n\r\n## Web Development for Monkeys\r\n\r\nWhen building web apps, most developers have editor and browser open side by side, with the browser immediately reflecting the changes they make in their code, thanks to modern frontend tools like [vite](https://github.com/vitejs/vite).
This works well enough while working on a single component of our app, but if you want to change an element that’s also on the same page but in an unrelated component tree, things start to break down. Sure, with a fuzzy finder you’ll probably find the correct file in a matter of seconds, but this requires some amount of context switching as you have to remember either the contents of the component or whatever obscure name you decided to give it. Now I might be outing myself as an utter idiot here, but sometimes this just can be too much for my monkey brain to handle. 🙈
Wouldn’t it be cool if you could just click on something in the browser and like magic the corresponding source file opens up in your editor instead? Monkey see 🐵, monkey click 🖱️, monkey magic 🐒🪄.\r\n\r\nWell, if you’re a Svelte developer, you’re in luck as this feature now comes built in with svelte! (Well more precisely with `@sveltejs/vite-plugin-svelte`, but it is very likely that your vite based svelte projects already use [this plugin](https://github.com/sveltejs/vite-plugin-svelte) under the hood). There even seem to be similar plugins for [vue](https://github.com/webfansplz/vite-plugin-vue-inspector) and [react](https://github.com/zthxxx/react-dev-inspector), but I’ll focus on svelte in this article, as it is the only one with an “official” integration that needs no further setup.\r\n\r\n## It Just Works™️\r\n\r\nThe only thing you have to do is set a config option in your `svelte.config.js` and you’re ready to go.\r\n\r\n```jsx\r\nexport default {\r\n vitePlugin: {\r\n inspector: true\r\n }\r\n};\r\n```\r\n\r\nNow with your editor open, fire up the dev server of your project with `npm run dev` and navigate to `http://localhost:5173/`.
If you press `cmd+shift` (`ctrl+shift` on linux, `cortana + w + shift + f12` on windows, or was it `ctrl+shift` too? ), you’ll notice your cursor change into the svelte logo wearing a party hat 🥳. Why a party hat? Well, it’s celebrating that you can now just click on any element on the page and your editor will open up the correct file, row and column. \r\n\r\nAmazing how it just works™️! That is, if you’re using vscode or any other of the supported [editor & operating system combinations](https://github.com/yyx990803/launch-editor#supported-editors). But let’s be real, you didn’t pick neovim as your editor because you expected stuff to work out of the box, but because you have no friends and thus don’t mind sacrificing weekends to tinker on your PDE (Personalized Development Environment or Private-life Dead End).\r\n\r\nFor an in-depth look into what happens behind the scenes of `@sveltejs/vite-plugin-svelte-inspector` and how this magic works so reliably, definitely give [Dominik G.’s talk from Svelte Summit Fall 2022](https://www.youtube.com/live/pJcbZr5VlV4?t=10421) a watch. (I even received a shoutout in the talk, [which I totally didn’t clip and watch every night before I fall asleep](https://www.youtube.com/clip/Ugkx7daLz3RhZCp4RbtB6-h1Lq-A33-P7FiN))\r\n\r\nFor our intents and purposes of bringing this experience to neovim, it’s enough to have a high level understanding what’s going on:\r\n\r\n1. Once you set `inspector: true`, the svelte inspector is [injected into](https://github.com/sveltejs/vite-plugin-svelte/blob/29f5e0a411c8dc7a420073cedf607a42bc5ba290/packages/vite-plugin-svelte-inspector/src/runtime/load-inspector.js#L3) your vite based svelte(kit) app via `@sveltejs/vite-plugin-svelte`\r\n2. Thanks to the `__svelte_meta` attribute, the inspector knows `file`, `row` & `column` of the source of a svelte component.\r\n3. With this information, the inspector performs a get request to the `/__open-in-editor?file=${location}` endpoint exposed by vite.js\r\n4. This endpoint leverages the package [yyx990803/launch-editor](https://github.com/yyx990803/launch-editor) to launch this file in your editor at the specified location\r\n\r\nThe flow above really showcases how well architected vite and its tooling is. The task of actually opening up files is neatly encapsulated to a single dependency: [yyx990803/launch-editor](https://github.com/yyx990803/launch-editor). Although the great architecture here shouldn’t come as a surprise, as you probably realized that the Github handle belongs to Evan You, the genius who initially built vite (& vue) in the first place.\r\n\r\n## Swimming Upstream: Vite’s Launch-Editor\r\n\r\nSo let’s swim upstream and look at the guts of `yyx990803/launch-editor`, so we can hack the damn thing!\r\n\r\nWhat actually happens when vite fetches `/__open-in-editor?file=${location}`?
At the core of `vite` is its dev server, which really just is a server that uses a bunch of [middlewares](https://expressjs.com/en/guide/using-middleware.html) that do cool stuff such as transforming files as you request them or, well, launching a process that opens a file just where you want it. \r\nIn fact, if we take a look at [line 620 of vite’s server implementation](https://github.com/vitejs/vite/blob/4f582c91d7e0e17c144fadf02a2b2ff485973ab5/packages/vite/src/node/server/index.ts#L620), we see that a suspicious `launchEditorMiddleware` is mounted to the `/__open-in-editor` path.\r\n\r\n```jsx\r\nmiddlewares.use('/__open-in-editor', launchEditorMiddleware())\r\n```\r\n\r\n[This middleware](https://github.com/yyx990803/launch-editor/blob/master/packages/launch-editor-middleware/index.js) essentially only checks the query param of our request to see if the necessary location data has been included. If it determine’s that the required information is there it passes it along to the function [launchEditor](https://github.com/yyx990803/launch-editor/blob/931700829d330cb95d173db1230d9ee2cb7c56ad/packages/launch-editor/index.js#L65), where `fileName` , `lineNumber` and `columnNumber` are extracted from it. The program then attempts [to guess our editor](https://github.com/yyx990803/launch-editor/blob/master/packages/launch-editor/guess.js), by looking at the processes currently running on our computer and comparing them with a list of common editor process names.\r\n\r\nWhile Evan You sadly was not coconut oil dev enough to straight up include neovim into this list, being a 10x dev he thought of adding a [fallback](https://github.com/yyx990803/launch-editor/blob/931700829d330cb95d173db1230d9ee2cb7c56ad/packages/launch-editor/guess.js#L97) way of detecting our preferred tool by using the `EDITOR` or `VISUAL` environment variables.\r\n\r\nSo if we just configure those environment variables to open neovim, we should be all set for a future of furious clicking?\r\n\r\n## “3 Levels of Monkey” Or: How to Over-engineer Everything\r\n\r\nSo we add `export EDITOR = 'nvim'` to our `.zshenv` (or wherever you manage your [shell environment variables](https://cgjennings.ca/articles/environment-variables/)) and repeat the steps from the [It Just Works™️](#it-just-works) chapter above.\r\n\r\nSo we\r\n\r\n1. Set `inspector: true`\r\n2. Start the dev server (`npm run dev`)\r\n3. Press `cmd+shift` to switch to the inspector view\r\n4. Click an element that we want to edit…\r\n\r\n… and 💥 BOOOM 💥, just like that, the relevant file opens up in beautiful neovim on the terminal at the exact position we want!\r\n\r\n### Monkey Level 1 **🐒**\r\n\r\nThis environment variable approach is **monkey level 1**: A cool thing that works out of the box, but comes with a set of annoying limitations… think of it like an iPhone📱: it lets you call your mom, endlessly swipe through tinder without ever getting matches and can even play your favorite nightcore tunes on Spotify. However, once you actually use it for a while, you realize its limitations: it doesn’t run Arch and won’t even allow you to set an animated waifu as the lockscreen.\r\n\r\nSo what are the limitations of simply using the `EDITOR` environment variable as a fallback? \r\n\r\n`launch_editor` opens your editor by spawning a child process with the file path, column and row as arguments. That means, every time you click to open, a new `nvim` process is started, which can lead of weird and ugly problems:\r\n\r\n- For example, you’ll quickly run into problems with swapfiles as multiple instances of neovim attempt to edit the same file [^1] [^2]\r\n- Even more annoyingly: I encountered a whole range of weird problems as plugins seem to run a lot less reliably\r\n- But most importantly: having `nvim` start up in the same terminal process covers the command line output of vite’s dev server, so you miss out on error messages or useful debug information, while your editor is open\r\n\r\nNow if you only plan on using this occasionally, there is absolutely nothing wrong with using it like this.\r\n\r\nWith that being said however, we wouldn’t be engineers if we did not massively over-engineer every pointless side project until it fit some obscure need, so let’s attempt to fix our nits with shitloads of duct-tape and wd-40.\r\n\r\n### Monkey Level 2 **🐒🐒**\r\n\r\nWhen I develop, I usually split my terminal into two panes, with the bottom pane running the dev server and the top pane running neovim, so I have both my editor and the server logs in sight.\r\nNow, what if there were a way to open the component we clicked on with `svelte inspector` not inside a new `nvim` sub process, but somehow funnel that information into the already running `nvim` process on top…?\r\n\r\nEnter: RPC Sockets 🔌.\r\n\r\n[RPC](https://en.wikipedia.org/wiki/Remote_procedure_call) is short for `Remote Procedure Call`, which translates for dummies means basically: “Make process in one place do something from another place.” So exactly like what we need!
So how do we communicate the things we want to do in place A (our editor process) from place B (our running dev server)? \r\n\r\nThis is where `Sockets` comes into play. [(IPC) Sockets](https://en.wikipedia.org/wiki/Unix_domain_socket) are a low level OS feature that can be used for bidirectional communication. Since in UNIX-land “everything is a file” at the core, a socket is nothing more than a special file that processes can read from or write to streams of data.
So if we wanted to `remotely call a procedure` in process B from process A, we could have process B listen to a socket, to which we then write procedures from process A.\r\n\r\n`Process A --write--> Socket <--read-- Process B`\r\n\r\nTurns out, the makers of nvim already anticipated us nerds wanting to do “spooky action at a distance”-kinda stuff with our editors, so they built an [easy-to use RPC API](https://neovim.io/doc/user/remote.html) into the tool.\r\n\r\nWhen starting neovim, you can pass the `—-listen {socketname}` flag, to specify a socket you want your neovim instance listen to. Then, from another process we can use `nvim --server {socketname} --remote-send {command}` to remotely execute commands.\r\n\r\nSo we could for example do something like `nvim --listen /tmp/my-first-socket` to start the process, then open another terminal process and execute `nvim --server /tmp/my-first-socket --remote-send \":q\"`.\r\n\r\n🎉 congrats 🎉 you just managed to [exit vim](https://stackoverflow.com/questions/11828270/how-do-i-exit-vim) from another dimension! \r\n\r\nNow that we got that joke out of the way, let’s think about how we can apply this knowledge to our problem and open up the file we want from svelte inspector.\r\n\r\nFirst, hop into your shell rc file so that we can create a little wrapper around neovim that allows us to start it with a socket without having to type all that much\r\n\r\n```bash\r\n# ~/.zshrc\r\n# \"remote vim\" wrapper to start a neovim instance listening to a socket\r\nrvim() {\r\n\tnvim --listen $REMOTE_VIM_SOCKET \"$@\"\r\n}\r\n```\r\n\r\nSo when we now open a file by using `rvim my-file.txt`, the neovim is ready to receive remote instructions via whatever socket we assign to the `$REMOTE_VIM_SOCKET` environment variable. Now all that’s left is setting up environment variables and creating a matching script that has to somehow be called when we click our browser using the svelte inspector.\r\n\r\nIf we go back to the implementation of launch_editor’s `guess.js`, we can see that there is an [early return on line 18 in case an environment variable named LAUNCH_EDITOR is set](https://github.com/yyx990803/launch-editor/blob/5ad87f680410710e261f4acdaddecaa808312029/packages/launch-editor/guess.js#L17). That’s just the escape hatch we need! (I wonder what genius proposed adding that environment variable… oh, [it was me](https://github.com/yyx990803/launch-editor/pull/39) 😮 I’m also on arch btw *tips fedora and makes sexy hissing sound*)\r\n\r\nTo make this work, let’s first built the script that is responsible for remotely opening the file. \r\n\r\nCreate a new script somewhere in your path (like `~/.local/bin` or some custom directory you [add to your path](https://unix.stackexchange.com/questions/26047/how-to-correctly-add-a-path-to-path)). I’ll go with `~/.local/bin/launch_editor_script` here.\r\n\r\n```bash\r\n#!/bin/bash\r\nfilename=$1\r\nline=${2:-\"1\"}\r\ncolumn=${3:-\"1\"}\r\ncommand=\"

:n $filename:call cursor($line,$column)\"\r\nnvim --server $REMOTE_VIM_SOCKET --remote-send $command\r\n```\r\n\r\nAs for the file contents, we add a shebang declaring which interpreter should be use when running this script. I use `bash`, because I am moderately sane, but feel free to use whatever obscure language you like, I’m sure future-you will be delighted when finding out you decided to write this utility in haskell!\r\n\r\nRemembering from earlier, we know that \r\n\r\n> `launch_editor` opens your editor by spawning a child process with the file path, column and row as arguments. \r\n\r\nWe thus know that the positional arguments passed to our script are\r\n\r\n1. `filename`\r\n2. `line`\r\n3. `column`\r\n\r\nAccordingly, lines 2-4 of our script assign those to named variables, providing fallbacks for line and column, in case they are not set.\r\n\r\nOn line 4 we then construct the command to open the file at the correct position. We first enter `

` to nope the f out from whatever vim mode you were in, use `:n $filename` to open the file and finally navigate to the right line and column with `:$line,$column`.\r\n\r\nFinally on line 5, we call our remote procedure on any neovim instance opened with the earlier `rvim` command.\r\n\r\nOnly a few things left to do: \r\n\r\nFirst, modify the permissions for the script we just created to make it executable: `chmod +x ~/.local/bin/launch_editor_script` \r\n\r\nLast but not least, set the required environment variables for this to work. (They need to be in the environment even for non-interactive shells, like the one spawned by node’s child process, so if you don’t know what you’re doing `.zshenv` probably is your best bet)\r\n\r\n```bash\r\n# .zshenv\r\nREMOTE_VIM_SOCKET=/tmp/remote-vim-socket\r\nLAUNCH_EDITOR=launch_editor_script\r\n```\r\n\r\nWith that done, open `rvim`, configure the svelte inspector and start your vite dev server… \r\nAnd just like magic, you should be able to click open your svelte files in the browser, with none of the limitations of our previous implementation!\r\n\r\nbut… you guessed it, we still can do better than this ``Monkey Level 2 Approach **🐒🐒**`!\r\n\r\nThere are still two major drawbacks to our approach:\r\n\r\n1. If we have multiple instances of `rvim` running, we might run into the same weird swapfile issues from before\r\n2. If I have to use a custom command like `rvim` to start nvim to be compatible with the svelte inspector, I will probably end up never using this feature. I don’t want to think about it, just have some utility function somewhere that I can forget about and stuff still just works.\r\n\r\n### Monkey Level 3 **🐒🐒🐒**\r\n\r\nThis is the point where we go absolutely b🍌n🍌n🍌s, throw out every ounce of reason and over-engineer the hell out of our little script.\r\n\r\nWhat if I told you, even when started without the `--listen` flag, nvim is controllable via Remote Procedure Calls…?\r\n\r\n> Nvim creates a default RPC socket at startup ([https://neovim.io/doc/user/api.html](https://neovim.io/doc/user/api.html))\r\n\r\n[Digging through neovim’s source code](https://github.com/neovim/neovim/blob/7c661207cc4357553ed2b057b6c8f28400024361/src/nvim/msgpack_rpc/server.c#L89), we find out that the name of this default RPC socket actually is always of the same shape and furthermore, contains a bunch of extremely valuable information.\r\n\r\n```bash\r\n/// - Other: \"/tmp/nvim.user/xxx/..\"\r\n```\r\n\r\nThe default sockets are all inside some special temporary directory, and contain the process id of the neovim process they belong to.\r\n\r\nBut how is that information going to help us solve the problems of our Monkey Level 2 approach?\r\n\r\nWell, if we want to get rid of the explicit usage of `rvim` to identify a special neovim instance, while at the same time making out launch_editor_script work for multiple arbitrary neovim instances opened simultaneously, we will need *some sort* of heuristic to decide which neovim instances we will send our remote procedure calls to.\r\n\r\nHold on for a sec, while I go full mad scientist here:
If we assume that the present working directory of our dev server will always be the same as the present working directory at the time we started neovim, we can use the present working directory as the parameter to figure out which dev process should trigger which neovim process.\r\n\r\n```sql\r\nTABLE ViteDevProcess (\r\n Name: 'vite dev'\r\n PID int,\r\n CWD varchar,\r\n);\r\n\r\nTABLE NvimSockets (\r\n PID int,\r\n CWD varchar,\r\n);\r\n\r\nSELECT *\r\nFROM NvimProcess \r\nLEFT JOIN ViteDevProcess \r\nON NvimProcess.CWD = ViteDevProcess.CWD;\r\n```\r\n\r\nIf we imagine our nvim and vite processes were each a table in a relational database, the above SQL is probably the most accurate description of what we’re trying to do here.\r\n\r\nSo let’s go to work and modify our code from Monkey Level 2 to do just that!\r\n\r\nFirst of all, let’s get rid of the stuff we won’t need anymore. Rip out that whole `rvim` function from your .bashrc and also remove the `REMOTE_VIM_SOCKET` environment variable, since we won’t need them anymore.\r\n\r\nFor our bash script, for now we can get rid of the actual remote procedure call, but we’ll reuse it almost unchanged at a later point\r\n\r\n```diff\r\n#!/bin/bash\r\nfilename=$1\r\nline=${2:-\"1\"}\r\ncolumn=${3:-\"1\"}\r\ncommand=\"

:n $filename:call cursor($line,$column)\"\r\n- nvim --server $REMOTE_VIM_SOCKET --remote-send $command\r\n```\r\n\r\nWe need to first construct our “table” of nvim sockets, to figure out where we might want to execute our Remote Procedure Calls. From the neovim implementation, we know that the sockets are nested somewhere inside `/tmp/nvim.user`, so we can use the `find` command to list them all up:\r\n\r\n```bash\r\n# nvim default sockets are always nested somewhere in here\r\nsocket_directory=\"${TMPDIR}nvim.${USER}\"\r\n# use find to, well, find them all! (-type s -> socket)\r\nnvim_sockets=($(find \"$socket_directory\" -type s))\r\n```\r\n\r\nNow that we have a big fat list of sockets, all that’s left to do is iterate over them, and find out which directory they were started from!\r\n\r\n```bash\r\nfor socket in \"${nvim_sockets[@]}\"\r\ndo\r\n # $socket is of shape: \"/tmp/nvim.user/xxx/..\"\r\ndone\r\n```\r\n\r\nSadly, this is where it get’s a bit nasty. We only have a list of socket names; that does not tell us anything about what directory their related nvim processes were started from.\r\n\r\nHowever, we can do some bash acrobatics to join our list of sockets with their `CWD` information!\r\n\r\nFirst, we extract the PID from the socket name:\r\n\r\n```bash\r\n# replace \"dots\" in socket with linebreaks and return the second to last line (the pid)\r\npid=($(echo $socket | tr \".\" \"\\n\" | tail -n 2))\r\n```\r\n\r\nthen we use `lsof` to find the processes’ `CWD`:\r\n\r\n```bash\r\n# use lsof to get table for this pid, grep row with file descriptor cwd \r\n# then replace spaces in row with linebreaks and return the second to last line (the pid)\r\npid_cwd=($(lsof -p $pid | grep cwd | tr \" \" \"\\n\" | tail -n 1))\r\n```\r\n\r\n> If this seems like sloppy coding to you, you’re totally right!
But by now I’ve spent way too much time on this little script, so gtfo 🤣\r\n\r\nFinally, we check if the pid_cwd is identical to the directory of the currently executing process (the vite process), and in case of a match, we make our Remote Procedure Call and…\r\n\r\n## tada~ 🎉 IT JUST WORKS! ™️\r\n\r\n![svelte_inspector1](https://github.com/Theo-Steiner/theosteiner.de/assets/40017636/426735a2-209f-4ac2-8703-7e0a73576036)\r\n\r\n### The final code:\r\n\r\n`~/.local/bin/launch_editor_script` :\r\n```bash\r\n#!/bin/bash\r\nfilename=$1\r\nline=${2:-\"1\"}\r\ncolumn=${3:-\"1\"}\r\n#

-> go to normal mode, open file, navigate to correct line and column\r\ncommand=\"

:n $filename:call cursor($line,$column)\"\r\n# nvim default sockets are always nested somewhere in here\r\n# see: https://github.com/neovim/neovim/blob/7c661207cc4357553ed2b057b6c8f28400024361/src/nvim/msgpack_rpc/server.c#L89\r\nsocket_directory=\"${TMPDIR}nvim.${USER}\"\r\n# use find to, well, find them all! (-type s -> socket)\r\nnvim_sockets=($(find \"$socket_directory\" -type s))\r\n\r\nfor socket in \"${nvim_sockets[@]}\"\r\ndo\r\n #now it gets nasty... \r\n #socket is of shape something.user.pid.count\r\n #so to get the pid we do this:\r\n #replace \"dots\" in socket with linebreaks and return the second to last line (the pid)\r\n pid=($(echo $socket | tr \".\" \"\\n\" | tail -n 2))\r\n #now we want to get the cwd this process is running in\r\n #use lsof to get table for this pid, grep row with file descriptor cwd \r\n #now replace spaces in row with linebreaks and return the second to last line (the pid)\r\n pid_cwd=($(lsof -p $pid | grep cwd | tr \" \" \"\\n\" | tail -n 1))\r\n #only if process cwd is the same as the pwd, run the command\r\n if [ $PWD == $pid_cwd ]; then\r\n nvim --server $socket --remote-send \"$command\"\r\n fi\r\ndone\r\n```\r\n```bash\r\n# .zshenv\r\nLAUNCH_EDITOR=launch_editor_script\r\n```\r\n\r\n [^1] The creators of launch_editor [anticipated this problem](https://github.com/yyx990803/launch-editor/blob/931700829d330cb95d173db1230d9ee2cb7c56ad/packages/launch-editor/index.js#L111), and provide a fix but sadly didn’t include `nvim` in it\r\n\r\n [^2] Note that [you can also configure neovim to be more forgiving when it comes to swapfiles](https://github.com/Theo-Steiner/.config/blob/0c7082eef92f2e4adacbd29afd6340839ee8ed45/nvim/lua/basics.lua#L43)","frontmatter":{"description":"Integrating Svelte's Inspector with Neovim allows you to simply click on components in your browser to edit their source code.","tags":["code","vite","svelte","neovim","click","svelte inspector"],"image":"https://user-images.githubusercontent.com/40017636/275247342-f2e5f994-9aea-4b74-bc0e-fd7277736170.png"},"title":"Open Neovim From Your Browser - Integrating nvim with Svelte’s Inspector","description":"Integrating Svelte's Inspector with Neovim allows you to simply click on components in your browser to edit their source code. ","category":"blog","tags":["code","vite","svelte","neovim","click","svelte inspector"],"image":"https://user-images.githubusercontent.com/40017636/275247342-f2e5f994-9aea-4b74-bc0e-fd7277736170.png","slug":"open-neovim-from-your-browser-integrating-nvim-with-sveltes-inspector","date":"2023-10-14T09:43:43.000Z","readingTime":"15 minutes","ghMetadata":{"issueUrl":"https://github.com/Theo-Steiner/theosteiner.de/issues/4","commentsUrl":"https://api.github.com/repos/Theo-Steiner/theosteiner.de/issues/4/comments","title":"Open Neovim From Your Browser - Integrating nvim with Svelte’s Inspector","created_at":"2023-10-14T09:43:43Z","updated_at":"2024-06-21T12:15:14Z","reactions":{"url":"https://api.github.com/repos/Theo-Steiner/theosteiner.de/issues/4/reactions","total_count":3,"+1":3,"-1":0,"laugh":0,"hooray":0,"confused":0,"heart":0,"rocket":0,"eyes":0}}},{"type":"blog","content":"\r\n## Don’t pick the wrong tool\r\n\r\nTheo recently published a video titled `Don’t pick the wrong tool` and as expected there are some spicy takes in it 🌶️. While I agree with much of what is said throughout the video, I think Theo got one fundamental thing wrong. And I even have a stupid car analogy to back it up 🚗.\r\n\r\nIf you haven’t seen it, go watch now: [https://www.youtube.com/watch?v=uEx9sZvTwuI](https://www.youtube.com/watch?v=uEx9sZvTwuI)\r\n\r\n> To those who think I have gone full mad and talk about myself in the third person: While I might be slightly mad, it turns out there’s actually more than one `Theo` out there… Who would have thought 🤯
\r\nBut it’s actually not confusing at all, because [my name](https://upload.wikimedia.org/wikipedia/commons/9/91/De-Theo.ogg) is pronounced `ˈteːo` while [@t3dotgg’s name](https://en.wiktionary.org/wiki/Theo) is `ˈθioʊ`. See, not confusing at all!\r\n> \r\n\r\n## The Bleeding Edge is a Gradient\r\n\r\nTo summarize the point of the video, Theo encourages the viewer to “bleed responsibly” arguing that the concept of `bleeding edge technology` is more nuanced than a simple `Technology A is new, therefore it is risky to use`. I am obviously simplifying here, but basically, Theo is suggesting that the risk associated with a new technology depends greatly on who is backing said technology.
\r\nApplied to the world of JavaScript frameworks this means that since the usage of React is orders of magnitude above the usage of Svelte, betting on the bleeding edge of the React ecosystem is associated with far less risk than betting on the bleeding edge of the Svelte ecosystem.\r\n\r\nSo far, I wholeheartedly agree: innovation doesn’t occur in a vacuum and the reputation and reach of the entity behind a new technology obviously influences its adoption in the long run. So if you want to benefit from the advancements of the bleeding edge, while at the same time keeping risks minimal, Reactland is where you wanna be!\r\n\r\nThe argument begins to break down however, once we move from the general to the specific case. While the bleeding edge for **technology A** in the React ecosystem is associated with less risk than the equivalent in the Svelte ecosystem, that does *not* automatically imply that **technology B** in React is also less risky than **technology A** in Svelte.
\r\n\r\nYup, this mysterious **technology B** I’m talking about is `React Server Components`.\r\nIn his video, Theo equates Next 13’s app directory with SvelteKit, and argues that betting on the former is less risky since it is part of the React ecosystem. I believe by doing so, he massively understates the paradigm shift that RSCs actually are, rendering his conclusion invalid. So here comes my time to shine by busting out a car analogy to explain this in the most conflated way possible!\r\n\r\n## What Car is Your JavaScript Stack?\r\n\r\nSo if `React` ecosystem were a car manufacturer, they'd probably be Toyota. Known for high quality and reliability, they sell the most cars while also sporting an amazing R&D department, where they constantly work on bleeding edge technology.\r\n\r\nLiterally any car technician on planet earth can service a Toyota, as the underlying technology of Internal Combustion Engines is well documented and the de-facto standard. You give it fuel (`jsx`) that the internal combustion engine (`the react library`) burns at runtime to propel the car (`render the app`).
\r\nNow, while you could just buy those car parts and build your custom ride from scratch, most people buy one of the prefabricated models on sale.\r\n\r\nThere’s quite a wide range of options to pick from, but the most popular one is the Corolla: `Next.js`. You literally can't go wrong when getting the newest model of this easy-to-use reliable ICE car for everyone that is stuffed to the brim with both proven technology and useful innovations.\r\n\r\nNow `Svelte` would be more of a “new-kid-on-the-block” Tesla. Unsatisfied with the tradeoffs of internal combustion engines, they decided to build battery electric vehicles instead. This comes with its own set of trade-offs, such as the need to charge (`compile`) ahead of time, as they can’t run on fuel (`templates`) directly. This however, allowed them to improve performance and reduce the complexity of the system.\r\n\r\nOther than the engine and a few minor details, the cars Tesla sells are almost identical to the ones that Toyota sells though. Their Model 3 (`SvelteKit`) is in the same price range as the Corolla (`Next.js`) and has comparable features.\r\n\r\nNow, whether or not you should buy a Model 3 over a Toyota Corolla is mostly down to personal preference and willingness to take risk. With the Corolla, you can get it fixed everywhere on earth and don’t have to worry about the infrastructure (`ecosystem`) not being developed yet, since ICE cars have been around for ages and will be around for a long time, however you will miss out on the improved performance of the electric powertrain.\r\n\r\nObviously, Toyota is not sleeping on the innovation though, and they are also planning to release battery electric vehicles (`React forget`).\r\n\r\nBut perhaps most excitingly they have a clear cut vision for the future: a deeply integrated hydrogen economy where surplus energy is used to produce liquid hydrogen that can be used in a new type of car. This hydrogen fueled car can be refueled quickly while retaining most benefits of the electric powertrain. They believe so much in this, that they literally named this car *Mirai*, which means future in Japanese. \r\nPerhaps also \"future\", because for now there exist about 1000 hydrogen fuel stations. Globally.\r\nNow could Toyota make the Hydrogen Economy happen? Probably! But a vision like that is difficult to materialize even for the biggest player.\r\n\r\nTo me `Next 13’s app directory` is the Toyota Mirai and `RSCs` are the React team’s hydrogen economy.
\r\nDon’t get me wrong, it’s all very exciting, but would you buy a Toyota Mirai over a Tesla Model 3 today? 🌶️\r\n","frontmatter":{"description":"A rebuttal of Theo's take on RSC being a less risky bet than SvelteKit.","tags":["code","react","svelte","javascript","RSC"]},"title":"Theo Got It Wrong or: What Car is Your JavaScript Stack?","description":"A rebuttal of Theo's take on RSC being a less risky bet than SvelteKit. ","category":"blog","tags":["code","react","svelte","javascript","rsc"],"slug":"theo-got-it-wrong-or-what-car-is-your-javascript-stack","date":"2023-07-08T06:52:22.000Z","readingTime":"5 minutes","ghMetadata":{"issueUrl":"https://github.com/Theo-Steiner/theosteiner.de/issues/3","commentsUrl":"https://api.github.com/repos/Theo-Steiner/theosteiner.de/issues/3/comments","title":"Theo Got It Wrong or: What Car is Your JavaScript Stack?","created_at":"2023-07-08T06:52:22Z","updated_at":"2023-07-09T05:23:13Z","reactions":{"url":"https://api.github.com/repos/Theo-Steiner/theosteiner.de/issues/3/reactions","total_count":16,"+1":0,"-1":0,"laugh":0,"hooray":0,"confused":0,"heart":16,"rocket":0,"eyes":0}}},{"type":"blog","content":"# Configuring Neovim for Debugging JavaScript Frameworks\r\n\r\n## I have to make a confession...\r\n\r\nWhen I have no clue whether or not the spaghetti code I wrote is al dente, I don't reach for a fancy JavaScript debugger like a proper Engineer, but instead arbitrarily disperse `console.log` statements throughout my code like the script kiddy I am.
Sometimes, when I don't feel like a bunch of `[object Object]`s are gonna take me where I wanna go, I use the full extend of my Engineering knowledge and skillfully `JSON.stringify` the application's current state onto the page.
\r\nI do realize however, that this technique is not likely to lead me to the 500k USD base compensation role I so badly need to offset my sushi consumption. So I decided that I had to expand my skillset and leave `console.log` behind me and learn debugger-jutsu to tackle mysterious stack overflows going forward.\r\n\r\nOnly Problem: Since I'm a show-off, I use Neovim - and how on earth do you debug JavaScript from a terminal based text editor?\r\n\r\n## The Objective\r\n\r\nBefore we dive into the config files, let us first establish what we are trying to accomplish here: Extending Neovim, so that we can debug code from (modern) JavaScript frameworks without leaving the editor.\r\n![debug_neovim_two](https://github.com/Theo-Steiner/theosteiner.de/assets/40017636/9a3e958e-3d11-4eb3-9062-1e731161e7e1)\r\nSince I mostly develop in Svelte.js, the settings shown here are only tested to work with Svelte and SvelteKit projects.
I don’t see a reason however, why this shouldn’t work for other JavaScript frameworks, such as React or Vue and I’ll highlight where I write svelte specific configuration, so you can adjust it to accommodate your JavaScript Flavor of choice. (Or give svelte.js a try and use the config as is ❤️)\r\n\r\nOne more caveat: In order to have my neovim boot up blazingly fast, I use folke’s lazy.nvim as a package manager.
If you use Packer or some other tool, you’ll have to change the lazy specific parts of my config. If you get stuck, check out [the lazy.nvim migration guide](https://github.com/folke/lazy.nvim#-migration-guide) that shows how lazy.nvim APIs map to the APIs of other package managers.\r\n\r\n\r\n## Getting Neovim to DAP\r\n\r\nSince vscode is a resource hungry, slow starting, evil corporation backed electron app I’m probably going to editor hell for saying this, but Microsoft really did an amazing job with its API design.
Just like how their [LSP (Language Server Protocol)](https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/) became the de-facto standard for communicating a language server’s diagnostics, types and completions to the editor, their [DAP (Debug Adapter Protocol)](https://microsoft.github.io/debug-adapter-protocol/specification) also standardized an Interface for brokering debugging related information between debug adapter and debug client.
These interoperable standards allow neovim to tap into the work others have done for vscode targetting language-tools and provide language integrations without having to reinvent the wheel.\r\n\r\nHowever, other than with the LSP, neovim does not natively support the DAP (yet). Lucky for us, neovim core team member mfussenegger publishes a plugin that provides an implementation of the Debug Adapter Protocol: [mfussenegger/nvim-dap](https://github.com/mfussenegger/nvim-dap).
Since my neckbeard is not yet developed enough for me to use this plugin as is, we do as n00bs have done for thousands of years and use a GUI to debug our stuff.
While I had some issues with the UI’s layout, [rcarriga/nvim-dap-ui](https://github.com/rcarriga/nvim-dap-ui) is a fantastic tool to interact with the debug adapter, although depending on your needs, you might also want to look into [theHamsta/nvim-dap-virtual-text](https://github.com/theHamsta/nvim-dap-virtual-text) to display the debug adapter’s information right inside your code.\r\n\r\nNow, let’s see what we need to do to make Neovim ~dab~ DAP!\r\n\r\n## Wiring up `nvim-dap` and `nvim-dap-ui`\r\n\r\nFirst, we’ll write a lazy.nvim plugin spec to install the two dependencies and configure everything we need in one place.\r\n\r\n```lua\r\n{\r\n\t\"mfussenegger/nvim-dap\",\r\n\tlazy = true,\r\n\tdependencies = {\r\n\t\t\"rcarriga/nvim-dap-ui\",\r\n\t},\r\n\tkeys = {\r\n\t\t{ \"d\", function() require('dap').toggle_breakpoint() end },\r\n\t\t{ \"c\", function() require('dap').continue() end },\r\n\t},\r\n\tconfig = function()\r\n\t\trequire(\"dapui\").setup()\r\n\tend\r\n}\r\n```\r\n\r\nThe plugin spec’s lazy property can be set to true, because you rarely debug something immediately after starting your editor. That that way the plugins don’t add to our startup time as they are lazily loaded once we call their keybinding.
For sake of simplicity, I only setup keybindings for toggling a breakpoint and “continuing”, that is launching debug sessions, here. You’ll probably also want to configure keybindings for `require('dap').step_over()` and `require('dap').step_into()`.\r\n\r\nFinally, we’ll add a config function, that will be called whenever lazy.nvim loads this plugin spec. For now, the callback only executes nvim-dap-ui’s setup function and then calls it a day.\r\n\r\n> Now that we have this set up, let’s give our config a whirl: \r\nRestart neovim, let lazy.nvim install the packages, head to your favorite JavaScript file and hit the keybinding to toggle a breakpoint. If you did everything correctly so far, a `B` should appear in your gutter, just next to the line number. Great!
\r\nIf we attempt to launch the debug session with our continue keybind though, we encounter an error: `DAP No configuration found for `language`. You need to add configs to `language` (See `:h dap-configuration`)`\r\n\r\nThe error suggests that we’re pretty close and just missing a configuration, but if you took a look at the scrollbar position to the right, you might have realized that this won’t be as easy as simply adding a config.\r\n\r\n## Missing Pieces: Config, Adapter and Debugger\r\n\r\nSo what even are we configuring? Neovim now supports the Debug Adapter *Protocol* but we are still missing the actual Debug Adapter that implements the interface.
Looking at [nvim-dap’s Debug Adapter installation wiki](https://github.com/mfussenegger/nvim-dap/wiki/Debug-Adapter-installation#vscode-js-debug), we learn that there usually is one debug adapter per language, and they are added to `nvim-dap` like so:\r\n\r\n```lua\r\n-- mock code for an adapter\r\nlocal dap = require('dap')\r\ndap.adapters.language = function(cb, config)\r\n if config.request == 'attach' then\r\n\t\tcb({type = \"server\", port = 9222})\r\n else if config.request == 'launch' then\r\n\t\tcb({type = 'executable', command = 'path/to/executable'})\r\n end\r\nend\r\n```\r\n\r\nThe above mock code shows that a `Debug Adapter` for a given language is nothing more than a function that takes two arguments: a callback and a config. The adapter then calls the callback function, passing along some settings based on the values of the config.
While I won’t go into details about how adapters work under the hood (read: I have no clue - probably magic!), let’s have a brief look at the config that’s passed to the adapter: the config object has a `request` property that can either be `attach` or `launch`.
In the context of debug adapters, this means we can either debug an already running process by *attaching* to it or *launch* a new process altogether for our debugging purposes.\r\n\r\nBut how do we actually attach to a process, how does `nvim-dap` communicate with node or chrome? We are missing one final piece of the puzzle: **the debugger itself**.\r\n\r\nFor JavaScript, [microsoft/vscode-js-debug](https://github.com/microsoft/vscode-js-debug) is the debugger of choice, as it combines debuggers for `node.js`, Chrome and more in one, actively maintained package. There even exists [mxsdev/nvim-dap-vscode-js](https://github.com/mxsdev/nvim-dap-vscode-js#user-content-fnref-1-b82b3ad3ace373e202d855e4d0ab8b68), a neovim plugin that provides a debug adapter for this debugger, so we don’t have to get into the weeds of handcrafting one ourselves.\r\n\r\n## Draw the Rest of the Owl\r\n\r\nDebugging JavaScript in Neovim (6 Servings)\r\n\r\n- GUI: `nvim-dap-ui`\r\n- DAP: `nvim-dap`\r\n- Adapter: `nvim-dap-vscode-js`\r\n- Debugger: `vscode-js-debug`\r\n\r\nSo now that we have identified all the ingredients for our debugging soup, let’s work our way up this list and first get our hands on a debugger.\r\n\r\n### Building the JavaScript Debugger from Source\r\n\r\nWe could manually download and extract the latest release of `vscode-js-debug` from [their \"releases\" page](https://github.com/microsoft/vscode-js-debug/releases), but we wouldn’t be engineers if we didn’t programmatically build the debugger from source. Since the repo for the debugger is hosted on github, we can leverage `lazy.nvim` to automatically do this for by just adding a nested lazy spec for a new dependency to our original lazy spec.\r\n\r\n```lua\r\n{\r\n\t\"mfussenegger/nvim-dap\",\r\n\tlazy = true,\r\n\tdependencies = {\r\n\t\t\"rcarriga/nvim-dap-ui\",\r\n\t\t-- lazy spec to build \"microsoft/vscode-js-debug\" from source\r\n\t\t{\r\n\t\t\t\"microsoft/vscode-js-debug\",\r\n\t\t\tversion = \"1.x\",\r\n\t\t\tbuild = \"npm i && npm run compile vsDebugServerBundle && mv dist out\"\r\n\t\t}\r\n\t},\r\n\tkeys = {...},\r\n\tconfig = function() ... end\r\n}\r\n```\r\n\r\nLet’s go over what this lazy spec does: \r\n\r\nBy specifying `version = \"1.x\"` we make sure that we only rebuild the debugger on new releases for version 1. That way, we don’t do the expensive rebuilding for every commit to the main branch or risk unknowingly running into breaking changes from a new major release. I set the version to `\"1.x\"` to still stay up to date, but you might as well specify a full release version here if you don’t want to automatically upgrade → `\"1.78.0\"` is the latest stable release at the time of writing this article.\r\n\r\nSo whenever a new release is published and we open neovim, we fetch the corresponding commit of the repository. However, since the debugger is written in typescript, we can’t use it as is, but need to compile it to JavaScript first. The `build` property in lazy specs allows us to specify commands for building a package. Here we first install the package’s dependencies with `npm i` and then run it’s compile script using `npm run compile vsDebugServerBundle`. Finally, we have to rename the `dist` folder where the compile output was written to, to `out`, as that’s the path that our debug adapter plugin expects. \r\n\r\n### Setting up our Debug Adapter: `nvim-dap-vscode-js`\r\n\r\nNext, we’ll configure the debug adapter plugin `nvim-dap-vscode-js`. \r\n\r\n```lua\r\n{\r\n\t\"mfussenegger/nvim-dap\",\r\n\tlazy = true,\r\n\tdependencies = {\r\n\t\t\"rcarriga/nvim-dap-ui\",\r\n\t\t\"mxsdev/nvim-dap-vscode-js\",\r\n\t\t-- lazy spec to build \"microsoft/vscode-js-debug\" from source\r\n\t\t{\r\n\t\t\t\"microsoft/vscode-js-debug\",\r\n\t\t\tversion = \"1.x\",\r\n\t\t\tbuild = \"npm i && npm run compile vsDebugServerBundle && mv dist out\"\r\n\t\t}\r\n\t},\r\n\tkeys = {...},\r\n\tconfig = function() \r\n\t\trequire(\"dap-vscode-js\").setup({\r\n\t\t\tdebugger_path = vim.fn.stdpath(\"data\") .. \"/lazy/vscode-js-debug\",\r\n\t\t\tadapters = { 'pwa-node', 'pwa-chrome', 'pwa-msedge', 'node-terminal', 'pwa-extensionHost' },\r\n\t\t})\r\n\t\trequire(\"dapui\").setup()\r\n\tend\r\n}\r\n```\r\n\r\nThe above lazy spec adds `mxsdev/nvim-dap-vscode-js` as a dependency and calls the debug adapter’s setup function in the config callback.
Here we pass it the path of the debugger we just built and specify which adapters we want it to register with `nvim-dap`.
For the `debugger_path` we just append neovim’s standard data path with `/lazy/vscode-js-debug` as the rest of the path to our debugger (`/out/src/dapDebugServer.js`) is hardcoded in the plugin.
I am telling `nvim-dap-vscode-js` to add all it’s available adapters to `nvim-dap` here, but you might as well just specify the adapters you need.\r\n\r\nIf we hit the keybind to continue/launch a debug session now, we will actually encounter the same error as earlier. This is because, while we have set up a debug adapter and debugger, we have yet to tell neovim which debug adapter to use for which language.\r\n\r\n### Adding Language Specific Configs to `nvim-dap`\r\n\r\nFor this, `nvim-dap` exposes a `configuration` setting, where we can configure debugging for the languages we need.\r\n\r\n```lua\r\nrequire(\"dap\").configurations.language_a = config_a\r\nrequire(\"dap\").configurations.language_b = config_b\r\n```\r\n\r\nThe config we pass here is not arbitrary, but a list of `debug actions` (my name, vs**de calls them `launch.json`s) that configure debug actions for a language.
Since most JavaScript frameworks will share this configuration, it is easiest to just put them all into a table and declaring the config iteratively.\r\n\r\n```lua\r\nfor _, language in ipairs({ \"typescript\", \"javascript\", \"svelte\" }) do\r\n\t\t\trequire(\"dap\").configurations[language] = {\r\n\t\t\t\t-- config goes here\r\n\t\t\t\t...\r\n\t\t\t}\r\nend\r\n```\r\n\r\nIf you want to debug something other than JS, TS or Svelte, this is where you need to declare your intention to do so! Just extend the table with `\"typescriptreact\"`, `\"vue\"` or whatever language matches your jam.\r\n\r\nNow is the part where things get interesting, as you can customize the `debug adapter config`s to fit your needs. I will go over the three `debug actions` I personally use in this article, but feel free to post your preferred configs, suggestions or fixes into the comments so other people can benefit from your knowledge!\r\n\r\n**1. Launch current file in new node process**\r\n\r\nThe first debug action (or `launch.json`) I’ll share here is for launching the current javascript file in node (and thus won’t work inside typescript, svelte or any other non-standard dialect).\r\n\r\n```lua\r\n{\r\n\t-- use nvim-dap-vscode-js's pwa-node debug adapter\r\n\ttype = \"pwa-node\",\r\n\t-- launch a new process to attach the debugger to\r\n\trequest = \"launch\",\r\n\t-- name of the debug action you have to select for this config\r\n\tname = \"Launch current file in new node process\",\r\n\tprogram = \"${file}\",\r\n\t}\r\n}\r\n```\r\n\r\n**2. Attach to an inspectable node process**\r\n\r\nThis debug action attaches to a node process that has been started with the\r\n`--inspect` or `--inspect-brk` flag. For long running tasks (like a dev server) usually just using `--inspect` will do, but for short lived tasks (like a one-off script) `--inspect-brk` is better suited, as it will delay execution until the debugger has attached instead of racing through the program before the debugger could communicate any breakpoints.\r\n\r\nBut let’s say you want to debug a long running npm script, to debug server side code in a SvelteKit app while running the dev server?
\r\nIf you want to debug a npm script, you can use the `--node-options` flag to pass along flags to the node binary when starting the script:\r\n\r\n```bash\r\n# start SvelteKit dev server with inspectable node process\r\nnpm --node-options --inspect-brk run dev\r\n```\r\n\r\nthe below debug action assumes some defaults to make debugging common web development projects more enjoyable, but you might need to play with it to get it working for the types of projects your working with (tested with SvelteKit, should work great with other vite based meta-frameworks)\r\n\r\n```lua\r\n{\r\n\t-- use nvim-dap-vscode-js's pwa-node debug adapter\r\n\ttype = \"pwa-node\",\r\n\t-- attach to an already running node process with --inspect flag\r\n -- default port: 9222\r\n\trequest = \"attach\",\r\n\t-- allows us to pick the process using a picker\r\n\tprocessId = require 'dap.utils'.pick_process,\r\n\t-- name of the debug action\r\n\tname = \"Attach debugger to existing `node --inspect` process\",\r\n\t-- for compiled languages like TypeScript or Svelte.js\r\n\tsourceMaps = true,\r\n\t-- resolve source maps in nested locations while ignoring node_modules\r\n\tresolveSourceMapLocations = { \"${workspaceFolder}/**\",\r\n\t\t\"!**/node_modules/**\"},\r\n\t-- path to src in vite based projects (and most other projects as well)\r\n\tcwd = \"${workspaceFolder}/src\",\r\n\t-- we don't want to debug code inside node_modules, so skip it!\r\n\tskipFiles = { \"${workspaceFolder}/node_modules/**/*.js\" },\r\n\t}\r\n},\r\n```\r\n\r\n**3. Debug the web in google chrome**\r\n\r\nThis launch action launches and immediately attaches to a debuggable chrome browser.\r\nSimilar to the previous one, this launch action also assumes some defaults to be tailored to a vite based dev experience.
For example, it assumes that your web app will run on port `5174` (default vite port) and skips a few vite specific files in the browser to not show you auto generated code while debugging. If you don’t use vite, you’ll be able to get it working with a bit of tweaking!\r\n\r\n```lua\r\n{\r\n\t-- use nvim-dap-vscode-js's pwa-chrome debug adapter\r\n\ttype = \"pwa-chrome\",\r\n\trequest = \"launch\",\r\n\t-- name of the debug action\r\n\tname = \"Launch Chrome to debug client side code\",\r\n\t-- default vite dev server url\r\n\turl = \"http://localhost:5173\",\r\n\t-- for TypeScript/Svelte\r\n\tsourceMaps = true,\r\n\twebRoot = \"${workspaceFolder}/src\",\r\n\tprotocol = \"inspector\",\r\n\tport = 9222,\r\n\t-- skip files from vite's hmr\r\n\tskipFiles = { \"**/node_modules/**/*\", \"**/@vite/*\", \"**/src/client/*\", \"**/src/*\" },\r\n},\r\n```\r\n\r\n### Last but not least: an automagic GUI!\r\n\r\nThe Debug Adapter Protocol exposes a few events we can hook into to have `nvim-dap-ui`'s GUI automagically open and close when we start or terminate our debug sessions. > I’ve found `nvim-dap-ui`'s GUI a bit finicky - with the breaking when repeatedly opening it. Passing `reset = true` when launching the GUI alleviates these problems a bit. \r\n\r\n```lua\r\nlocal dap, dapui = require(\"dap\"), require(\"dapui\")\r\ndap.listeners.after.event_initialized[\"dapui_config\"] = function()\r\n\tdapui.open({ reset = true })\r\nend\r\ndap.listeners.before.event_terminated[\"dapui_config\"] = dapui.close\r\ndap.listeners.before.event_exited[\"dapui_config\"] = dapui.close\r\n```\r\n\r\nWhile this works reliably in about ~85% of cases, you might still want to map `require(\"dapui\").toggle()` to some key, as there are cases where the UI sticks around after an error and closing all it’s windows manually can be a bit of a pain.\r\n\r\n## Putting it all together!\r\n\r\nI know, I know. This article was way too long and by now you’re probably sick of my writing style, but trust me: the payoff is worth it!\r\n\r\nFirst, let’s put all the pieces together for the final lazy spec you can copy and paste into your code:\r\n\r\n```lua\r\nrequire(\"lazy\").setup({\r\n\t...,\r\n\t{\r\n\t\t\"mfussenegger/nvim-dap\",\r\n\t\tdependencies = {\r\n\t\t\t\"rcarriga/nvim-dap-ui\",\r\n\t\t\t\"mxsdev/nvim-dap-vscode-js\",\r\n\t\t\t-- build debugger from source\r\n\t\t\t{\r\n\t\t\t\t\"microsoft/vscode-js-debug\",\r\n\t\t\t\tversion = \"1.x\",\r\n\t\t\t\tbuild = \"npm i && npm run compile vsDebugServerBundle && mv dist out\"\r\n\t\t\t}\r\n\t\t},\r\n\t\tkeys = {\r\n\t\t\t-- normal mode is default\r\n\t\t\t{ \"d\", function() require 'dap'.toggle_breakpoint() end },\r\n\t\t\t{ \"c\", function() require 'dap'.continue() end },\r\n\t\t\t{ \"\", function() require 'dap'.step_over() end },\r\n\t\t\t{ \"\", function() require 'dap'.step_into() end },\r\n\t\t\t{ \"\", function() require 'dap'.step_out() end },\r\n\t\t},\r\n\t\tconfig = function()\r\n\t\t\trequire(\"dap-vscode-js\").setup({\r\n\t\t\t\tdebugger_path = vim.fn.stdpath(\"data\") .. \"/lazy/vscode-js-debug\",\r\n\t\t\t\tadapters = { 'pwa-node', 'pwa-chrome', 'pwa-msedge', 'node-terminal', 'pwa-extensionHost' },\r\n\t\t\t})\r\n\t\r\n\t\tfor _, language in ipairs({ \"typescript\", \"javascript\", \"svelte\" }) do\r\n\t\t\t\trequire(\"dap\").configurations[language] = {\r\n\t\t\t\t\t-- attach to a node process that has been started with\r\n\t\t\t\t\t-- `--inspect` for longrunning tasks or `--inspect-brk` for short tasks\r\n\t\t\t\t\t-- npm script -> `node --inspect-brk ./node_modules/.bin/vite dev`\r\n\t\t\t\t\t{\r\n\t\t\t\t\t\t-- use nvim-dap-vscode-js's pwa-node debug adapter\r\n\t\t\t\t\t\ttype = \"pwa-node\",\r\n\t\t\t\t\t\t-- attach to an already running node process with --inspect flag\r\n\t\t\t\t\t\t-- default port: 9222\r\n\t\t\t\t\t\trequest = \"attach\",\r\n\t\t\t\t\t\t-- allows us to pick the process using a picker\r\n\t\t\t\t\t\tprocessId = require 'dap.utils'.pick_process,\r\n\t\t\t\t\t\t-- name of the debug action you have to select for this config\r\n\t\t\t\t\t\tname = \"Attach debugger to existing `node --inspect` process\",\r\n\t\t\t\t\t\t-- for compiled languages like TypeScript or Svelte.js\r\n\t\t\t\t\t\tsourceMaps = true,\r\n\t\t\t\t\t\t-- resolve source maps in nested locations while ignoring node_modules\r\n\t\t\t\t\t\tresolveSourceMapLocations = {\r\n\t\t\t\t\t\t\t\"${workspaceFolder}/**\",\r\n\t\t\t\t\t\t\t\"!**/node_modules/**\" },\r\n\t\t\t\t\t\t-- path to src in vite based projects (and most other projects as well)\r\n\t\t\t\t\t\tcwd = \"${workspaceFolder}/src\",\r\n\t\t\t\t\t\t-- we don't want to debug code inside node_modules, so skip it!\r\n\t\t\t\t\t\tskipFiles = { \"${workspaceFolder}/node_modules/**/*.js\" },\r\n\t\t\t\t\t},\r\n\t\t\t\t\t{\r\n\t\t\t\t\t\ttype = \"pwa-chrome\",\r\n\t\t\t\t\t\tname = \"Launch Chrome to debug client\",\r\n\t\t\t\t\t\trequest = \"launch\",\r\n\t\t\t\t\t\turl = \"http://localhost:5173\",\r\n\t\t\t\t\t\tsourceMaps = true,\r\n\t\t\t\t\t\tprotocol = \"inspector\",\r\n\t\t\t\t\t\tport = 9222,\r\n\t\t\t\t\t\twebRoot = \"${workspaceFolder}/src\",\r\n\t\t\t\t\t\t-- skip files from vite's hmr\r\n\t\t\t\t\t\tskipFiles = { \"**/node_modules/**/*\", \"**/@vite/*\", \"**/src/client/*\", \"**/src/*\" },\r\n\t\t\t\t\t},\r\n\t\t\t\t\t-- only if language is javascript, offer this debug action\r\n\t\t\t\t\tlanguage == \"javascript\" and {\r\n\t\t\t\t\t\t-- use nvim-dap-vscode-js's pwa-node debug adapter\r\n\t\t\t\t\t\ttype = \"pwa-node\",\r\n\t\t\t\t\t\t-- launch a new process to attach the debugger to\r\n\t\t\t\t\t\trequest = \"launch\",\r\n\t\t\t\t\t\t-- name of the debug action you have to select for this config\r\n\t\t\t\t\t\tname = \"Launch file in new node process\",\r\n\t\t\t\t\t\t-- launch current file\r\n\t\t\t\t\t\tprogram = \"${file}\",\r\n\t\t\t\t\t\tcwd = \"${workspaceFolder}\",\r\n\t\t\t\t\t} or nil,\r\n\t\t\t\t}\r\n\t\t\tend\r\n\t\r\n\t\t\trequire(\"dapui\").setup()\r\n\t\t\tlocal dap, dapui = require(\"dap\"), require(\"dapui\")\r\n\t\t\tdap.listeners.after.event_initialized[\"dapui_config\"] = function()\r\n\t\t\t\tdapui.open({ reset = true })\r\n\t\t\tend\r\n\t\t\tdap.listeners.before.event_terminated[\"dapui_config\"] = dapui.close\r\n\t\t\tdap.listeners.before.event_exited[\"dapui_config\"] = dapui.close\r\n\t\tend\r\n\t}\r\n})\r\n```\r\n\r\n## Neovim Debugging in Action\r\n\r\n### Debugging plain old JavaScript\r\n\r\n![debug_neovim_two](https://github.com/Theo-Steiner/theosteiner.de/assets/40017636/9a3e958e-3d11-4eb3-9062-1e731161e7e1)\r\n\r\nNow with everything setup, let’s see it in action.
\r\nLet’s do a test run with a plain JavaScript file first:
\r\nOpen up a new file in neovim `nvim index.js` & write some random code:\r\n\r\n```jsx\r\nvar str = \"neovim\"\r\nstr = \"debugger\"\r\nconsole.log(`hello ${str}`)\r\n```\r\n\r\nNow enter `gg` to jump back to line 1 and hit that keybind to add breakpoint to the current line (`d` in the config above). If a `B` shows up at the very left, everything is setup correctly.\r\n\r\nNow let’s start up the debugging session (`c`). You should be prompted with three options now:\r\n\r\n```\r\n│1: Attach debugger to existing `node --inspect` process\r\n│2: Launch Chrome to debug client\r\n│3: Launch file in new node process\r\n│Type number and or click with the mouse (q or empty cancels):\r\n```\r\n\r\nFor now, let’s select option 3: Launch file in new node process. Just type `3` and hit enter.\r\n\r\nThis will now open a few windows, which show you the current state of the runtime. Since the GUI is just comprised of windows, we can easily switch focus between them. For example, if we type `` followed by `h`, we end up in the left top window, titled “DAP Watches”. Here we can write javascript statements and expressions with the current debugger state. I’ve bound `require 'dap'.step_over()` to ``, so I can use that keybinding to step through the lines of code, and use the GUI to see the current values I’m interested in.\r\n\r\n### Debugging Client Side JavaScript\r\n\r\n![svelte_client](https://github.com/Theo-Steiner/theosteiner.de/assets/40017636/727ba95a-6058-4056-8ac5-5903f2972dde)\r\n\r\nTo debug Client Side Javascript, the concept is the same, but the steps are a bit different. Let’s go through it and try to debug the very SvelteKit site you’re reading this article on. Here are the necessary steps:\r\n\r\n1. We start up the dev server as we usually would.\r\n2. We edit the code with neovim and encounter some place we’d like to debug.\r\n3. We set a breakpoint and start a debug session. \r\n4. This time around, we select option two `2: Launch Chrome to debug client`\r\n\r\nWhen the breakpoint is triggered on the client side, execution will stop and inspect the current state and step through the execution in chrome from the comfort of your own editor!\r\n\r\n### Debugging Server Side JavaScript\r\n\r\nBasically almost the same thing again, but now we have to pass a flag when starting the dev server, so we can connect the debugger to it.\r\n\r\n1. We start up the dev server as we usually would, but pass a flag to node\r\n`npm run dev` → `npm --node-options --inspect run dev`\r\n2. We edit the code with neovim and encounter some place we’d like to debug.\r\n3. We set a breakpoint and start a debug session. \r\n4. This time we select option `1: Attach debugger to existing node --inspect process`\r\n5. Now we are prompted with a menu to select the process, enter the number corresponding to the process you want to debug and hit enter \r\n\r\nAs before, once your code reaches a breakpoint, execution will stop and you get to debug in style!\r\n\r\nI hope this article helped you in setting up Neovim to your liking. Happy Debugging! 🤖","frontmatter":{"description":"A guide on how to setup debugging for JavaScript projects in neovim. Learn how to debug svelte, react or vue without having to leave your editor.","tags":["code","nvim","svelte","javascript","guide"]},"title":"Debugging JavaScript Frameworks in Neovim","description":"A guide on how to setup debugging for JavaScript projects in neovim. Learn how to debug svelte, react or vue without having to leave your editor. ","category":"blog","tags":["code","nvim","svelte","javascript","guide"],"slug":"debugging-javascript-frameworks-in-neovim","date":"2023-06-04T09:45:44.000Z","readingTime":"15 minutes","ghMetadata":{"issueUrl":"https://github.com/Theo-Steiner/theosteiner.de/issues/2","commentsUrl":"https://api.github.com/repos/Theo-Steiner/theosteiner.de/issues/2/comments","title":"Debugging JavaScript Frameworks in Neovim","created_at":"2023-06-04T09:45:44Z","updated_at":"2024-09-05T06:49:21Z","reactions":{"url":"https://api.github.com/repos/Theo-Steiner/theosteiner.de/issues/2/reactions","total_count":14,"+1":0,"-1":0,"laugh":0,"hooray":0,"confused":0,"heart":14,"rocket":0,"eyes":0}}},{"type":"blog","content":"## Vue Type Errors only inside Neovim\r\n\r\nSo you finally did it! 🎉
Wiped that memory hugger named vs**de from your system, installed neovim nightly and worked through ThePrimeagen's guide of how to set up neovim as your own, private IDE with git integration, fuzzy find and lsp integration.
Filled with glee, you go back to your day job of changing button colors on the interwebs - ready to prove to the world that you are now a 10x developer well deserving of that pay raise you have been denied for so long.\r\n\r\nBut wait, what is that? 😨
Upon opening your trusty `vue.js` project in neovim, the newly setup native lsp client suddenly begins flooding your screen with type errors, when you could have sworn everything compiled fine just a day ago.
And your memory is correct: when running `npx vue-tsc` on the file drowned in errors, everything compiles without any problems.
What's going on here? What is the `tsserver` you painstakingly set up with `mason.nvim` suddenly so upset about?\r\n\r\nTurns out, type checking inside vue projects in vs**de is not actually done by tsserver in most cases anymore.
Vue's language server `Volar` has a `Takeover mode` that allows it to entirely take over and conduct all type checking in tsserver's place. This means Volar is responsible for typechecking even the `.ts` files of your vue project.\r\n\r\nHere's what [the official Vue docs](https://vuejs.org/guide/typescript/overview.html#volar-takeover-mode) have to say about this:\r\n> To get Vue SFCs and TypeScript working together, Volar creates a separate TS language service instance patched with Vue-specific support, and uses it in Vue SFCs. At the same time, plain TS files are still handled by VSCode's built-in TS language service, which is why we need [TypeScript Vue Plugin](https://marketplace.visualstudio.com/items?itemName=Vue.vscode-typescript-vue-plugin) to support Vue SFC imports in TS files.\r\n\r\n## Letting Volar take over inside Neovim\r\n\r\nSo how do we get the takeover mode to work inside neovim's native LSP client? \r\n\r\n### 1. Manual Configuration\r\nSo an obvious but also very tedious way to solving this issue would be to quickly edit your neovim config before working on your vue projects.
In your lsp settings, you simply don't let `tsserver` attach and modify the filetypes for Volar to include \".ts\" files.\r\n\r\n```lua\r\nlocal default_servers = {\r\n -- don't setup tsserver, as we want volar to take over\r\n -- 'tsserver',\r\n 'volar',\r\n}\r\n\r\nrequire('mason-lspconfig').setup_handlers({\r\n\tfunction(server_name)\r\n local server_config = nil\r\n\t\tif server_name == 'volar' then \r\n\t\t\t{filetypes = { 'vue', 'typescript', 'javascript' }}\r\n\t\tend\r\n\t\tlspconfig[server_name].setup(\r\n\t\t\tserver_config\r\n\t\t)\r\n\tend,\r\n})\r\n```\r\n\r\nYou can however see, how this could quickly become tedious. Especially if you work in `vue` projects only sometimes and thus might simply forget about setting this when switching between programs.
So perhaps we can find a way to setting this up, that's comparable to how you would configure the VSCode extension. Meaning that everything is automatic after the initial setup and we don't have to edit our vimconfig every time we want to work on a vue project.\r\n\r\n### 2. Automatic Configuration - Set and Forget\r\n\r\nAt work, I mostly write vue, but in my free time, I prefer to work in svelte. So configuring this every day would be a major PITA. We're engineers, we should not do manual labor like that!
\r\nThankfully neovim has a great plugin ecosystem and lua API that allows us to automate away repetitive tasks like this.
\r\nLet's dive into how I use lua to automate this configuration (mostly) away.\r\n\r\n### Preparation:\r\n\r\nFirst, you need to install [folke/neoconf.nvim](https://github.com/folke/neoconf.nvim) and call it's setup function before you setup mason or your lsp-config. Neoconf is a neovim plugin that allows us to configure project-specific (and global) settings.\r\n\r\n```lua\r\nrequire(\"neodev\").setup({})\r\nrequire(\"mason\").setup()\r\nrequire('mason-lspconfig').setup({\r\n ensure_installed = {\"volar\"}\r\n})\r\nlocal lspconfig = require('lspconfig')\r\n\r\nrequire('mason-lspconfig').setup_handlers({\r\n function(server_name)\r\n local server_config = {}\r\n lspconfig[server_name].setup(server_config)\r\n end,\r\n})\r\n```\r\n\r\nWith this setup, you want to think about a syntax to use to disable the TypeScript server, so that Volar can take over its duties. I went with a simple \"disable\" that is false-y by default and has to be set to true manually.\r\n\r\n```json\r\n{\r\n\"tsserver\": { \"disable\": true }\r\n}\r\n```\r\n\r\nYou now create a `.neoconfig.json` file with the above contents at the root of your Vue project. (You can also run the command `:Neoconf` to do this from within nvim)\r\n\r\n### Now comes the cool part:\r\n\r\nBecause the author of Neoconf, folke, is an absolute genius, this plugin has a very elegant api that allows us to get the contents of the `.neoconfig.json` file easily. So we can just call the following API to see whether or not we want the typescript language server to boot. `require(\"neoconf\").get(\"tsserver.disable\")` \r\n\r\nLet's integrate this into our config:\r\n\r\n```lua\r\nrequire('mason-lspconfig').setup_handlers({\r\n function(server_name)\r\n local server_config = {}\r\n if require(\"neoconf\").get(server_name .. \".disable\") then\r\n return\r\n end\r\n lspconfig[server_name].setup(server_config)\r\n end\r\n})\r\n```\r\n\r\nNow there is only one thing left to do: typescript is not in the default supported filetypes for volar, so we need to add it like so:\r\n```lua\r\nif server_name == \"volar\" then\r\n server_config.filetypes = { 'vue', 'typescript', 'javascript' }\r\nend\r\n```\r\nNow whenever we open a typescript file in the workspace with .neoconf.json at its root, tsserver won't boot and instead volar attaches to the buffer!\r\n\r\n### Final Code:\r\n\r\n```lua\r\nrequire(\"neodev\").setup({})\r\nrequire(\"mason\").setup()\r\nrequire('mason-lspconfig').setup({\r\n ensure_installed = {\"volar\", \"tsserver\"}\r\n})\r\nlocal lspconfig = require('lspconfig')\r\n\r\nrequire('mason-lspconfig').setup_handlers({\r\n function(server_name)\r\n local server_config = {}\r\n if require(\"neoconf\").get(server_name .. \".disable\") then\r\n return\r\n end\r\n if server_name == \"volar\" then\r\n server_config.filetypes = { 'vue', 'typescript', 'javascript' }\r\n end\r\n lspconfig[server_name].setup(server_config)\r\n end,\r\n})\r\n```\r\n\r\nIt personally took me quite a while to find out the cause of why I suddenly got unexpected TypeScript errors, so I hope this article is helpful to some fellow nvim-aficionado web developers!\r\n\r\nFeel free to check my [dotfiles](https://github.com/Theo-Steiner/.config/blob/main/nvim/lua/ide/lsp/init.lua) if you're interested in how I integrated this with the rest of my lsp configuration or my other configuration.\r\n","frontmatter":{"description":"A guide on how to setup neovim to enable Volar's takeover mode to allow vscode like type checking of vue projects in nvim","tags":["code","nvim","vue","volar"]},"title":"Using Volar's Takeover mode in Neovim's Native LSP Client","description":"A guide on how to setup neovim to enable Volar's takeover mode to allow vscode like type checking of vue projects in nvim ","category":"blog","tags":["code","nvim","vue","volar"],"slug":"using-volars-takeover-mode-in-neovims-native-lsp-client","date":"2023-05-14T10:32:08.000Z","readingTime":"5 minutes","ghMetadata":{"issueUrl":"https://github.com/Theo-Steiner/theosteiner.de/issues/1","commentsUrl":"https://api.github.com/repos/Theo-Steiner/theosteiner.de/issues/1/comments","title":"Using Volar's Takeover mode in Neovim's Native LSP Client","created_at":"2023-05-14T10:32:08Z","updated_at":"2024-01-09T19:01:28Z","reactions":{"url":"https://api.github.com/repos/Theo-Steiner/theosteiner.de/issues/1/reactions","total_count":10,"+1":10,"-1":0,"laugh":0,"hooray":0,"confused":0,"heart":0,"rocket":0,"eyes":0}}}]

Blog