Joshua's Docs - VSCode Settings, Power User Tips, and Misc Notes
Light

Opening Via CLI

Opening Via CLI - Windows

VSCode is exposed, via the system PATH, as code. This allows you to do the following, in a standard command prompt:

  • Open a directory: code {dir}

    • You can use code . for opening the current directory
  • Open a specific file code {filePath}

If you notice that every time you open a file with this method, it also opens a file called cli.js, there is likely a permission mismatch; e.g. you set Code.exe to always open as an Administrator, but the console you called code from was not launched as an administrator.

  • The fix here is to simply use an elevated command prompt, or remove the setting that code.exe always run with Administrator privileges.
  • Relevant issues: #72521, #91613

Troubleshooting

  • Stale path / environment variables in terminal

    • Try completely restarting VSCode - close all windows and relaunch
    • Try running VSCode as an administrator; this can often fix path expansion issues

    • Check which shell you are using as the intergrated terminal

      • You can override with settings.json -> terminal.integrated.shell.{OS}

  • TypeScript import autocomplete keeps using absolute or incorrect relative paths

    • Try setting settings.json -> "typescript.preferences.importModuleSpecifier": "relative"

🔗 - Resource: VSCode - Common Error Cases

Debugging / Launching

Debugging Resources

Launch.json Tips

  • For Yarn, set runtimeExecutable to "yarn", and runtimeArgs should just be an array of the commands you would normally type after yarn run. E.g:

    {
	"runtimeExecutable": "yarn",
	"runtimeArgs": ["debug-build"],
}

  • If you have breakpoints for all "Uncaught Exceptions" on, you might want to exclude node_modules, or any other third-party directory, from that rule (if you are seeing a bunch of exceptions you don't care about).

    • You can do this with the skipFiles feature.
    • Example: "skipFiles": ["<node_internals>/**", "${workspaceFolder}/node_modules/**/*.js"]

  • Viewing the results in the integrated console

    • Use "console": "integratedTerminal"

Strange Issue with Auto-Attach

I've noticed a strange issue with auto-attach in VSCode. Even if I have it turned on, it (the VSCode debugger) often will not work if Chrome is open, although the auto-attacher in Chrome works just fine. It's almost like Chrome is hijacking the debugger port or something.

The fix for me was to manually create a launch.json entry, rather than relying on only the --inspect-brk or --inspect flag for Node. In addition, make sure the entry has type: "node", not type: "chrome".

If you don't have a launch.json file, you can also try toggling autoattach on & off via the command palette (or look at the bottom left of the window for the toggle status)

Manual Attachment

If auto-attach is not working for you, another option is to manually attach to a running node process; open the Command Palette and then run the Attach to Node Process command. Details here

Settings

For my personal settings, see /settings.

Disable annoying word autocomplete

{
	"editor.wordBasedSuggestions": false,
	"javascript.suggest.names": false
}

Setup basic code formatting rules

{
	"editor.tabSize": 4
}

Disable CRLF (\r\n) endings on Windows

{
	"files.eol": "\n"
}

Force indent style

If you really want to ensure a specific indent style in a shared repo, this is a forceful way to do so, in your .vscode/settings.json:

{
	"editor.insertSpaces": true,
	"editor.tabSize": 4,
	"editor.detectIndentation": false,
	"editor.formatOnSave": true,
	"editor.autoIndent": "full"
}

Change Linting / Error Styling

The main way that VSCode tracks if something is a "problem" is by having it flagged as either a warning or an error. Linters plug into this system, instead of defining their own types of problems, so unfortunately customization is often limited.

The first way to customize warnings and errors is in our VSCode settings.json to use workbench.colorCustomizations and the nested sub-properties for editorError.__, editorWarning.__, etc. For example, if we wanted to change the error red squiggly to appear lighter, with some opacity, we could use:

"workbench.colorCustomizations": {
	"editorError.foreground": "#ff00006e"
}

The second way is to have your linter actually emit different problem types to VSCode. For example, you can tell your linter to report all lint violations as warning instead of error:

🚨 -- WARNING -- 🚨: In general, having your linter emit warnings instead of errors is not a great idea, especially for large codebases that rely on automated lint checks to enforce clean PRs; this could allow lint tests to pass that should really fail.

Extensions:

Per workspace settings

You can control settings per root directory (workspace/project) through {WORKSPACE_ROOT}/.vscode/settings.json.

  • This file will be automatically created if you touch a workspace level setting (through the GUI), but you can also manually create it:

    • mkdir .vscode && touch .vscode/settings.json

You can add a file (extensions.json) to your workspace .vscode folder, so that when other devs checkout your code, VSCode will recommend for them to install the extensions that will help them the most. Read more here.

Snippets

Main doc: User Defined Snippets

There is a lot in this doc, so make sure to read carefully!

Advanced Transforms

  • Examples:

    • Official docs: here

  • Escaping: It's complicated!

  • Combining tab-stops with variables

    • You can combine tab-stops (where the cursor tabs between) and variable / macros, by nesting:
    • Example: "src=\"${1:${CLIPBOARD:IMAGE_SOURCE}}\"

Javascript Type Safety

There are are a bunch of options for getting some type-safety with JS in VScode, and better intellisense. Of course, you are free to also use linters, like ESLint (see my JS DevOps Cheatsheet), but that is not the only option. There is actually built-in type checking options!

To get the full power of this feature, you really should use JSDoc comments to provide additional type annotations, control inferred types, and so on. This is a hefty topic, so I've moved all my notes on it to a dedicated JSDoc cheatsheet page, under this section.

Recovering Work or Files

I won't lecture you on proper file backups and version control systems, but will just say this should only be used as a last resort.

VSCode does actually maintain some backups and revision history. This S/O should steer you in the right direction for finding the main backups folder. You can also try the Command Palette - Developer: Open Logs Folder - and then go up from that directory until you find the parent folder with the Backup folder inside it.

There is probably also some sort of internal database / repository for managing local edit operations, so that undo and redo can work, but I'm not sure how to easily access that.

Coming from Notepad++ / "where is X?"

If you are coming from using Notepad++, or a vastly different IDE, you might be looking for certain things. For example:

  • "Show all characters"

    • In Notepad++, this shows whitespace characters (\t, \s, etc.), as well as EOL (end of line) characters (\r or \n). I have not a single method to do both on VSCode, but you can do them separately.

      • Whitespace: Menu -> View -> Render Whitespace
      • EOL: There is an extension that shows them

  • How do I view the file summary, with word-count, etc.?

    • There is no one "summary" view, but character count can be tabulated by selecting text (displays in bottom bar by default), and word count can be displayed by installing an extension, such as Microsoft's aptly named "Word Count"

Searching

  • You can use regex

  • You can filter your search by specific files and by directory

    • See guide here
    • Uses glob syntax
    • Use , to separate multiple patterns
    • Use ! to negate a pattern

  • You can exclude files and directories

    • Inherits settings from .gitignore and global settings

Linting / Formatting Controls

Built-in

First, I want to point out that you can customize settings per language in VSCode, no extension required. Just put the language specifier as the JSON key, and then the settings as the object value. Like so:

{
	"editor.tabSize": 4,
	"[php]": {
		"editor.tabSize": 2
	}
}

You can even specify certain actions to be ran after certain file types are saved, by using editor.codeActionsOnSave under a language specifier!

If you are have multiple language formatting extensions installed, and want to tell VSCode which one to use per language, that is another thing you can do with settings:

{
	"[php]": {
		"editor.defaultFormatter": "vscode.php-language-features"
	}
}

JS Linting

Check out my notes here.

Building an extension

For right now, my only public notes on this are on my blog: https://joshuatz.com/posts/2019/building-a-vscode-extension-some-tips-and-tricks/

Markdown Source Last Updated:
Sun Dec 27 2020 11:17:44 GMT+0000 (Coordinated Universal Time)
Markdown Source Created:
Mon Aug 26 2019 07:49:42 GMT+0000 (Coordinated Universal Time)
© 2021 Joshua Tzucker, Built with Gatsby
Feedback