The Frontend Developer's Config Sync Checklist

Frontend development involves a staggering number of configuration files. Between your editor, linter, formatter, package manager, Node.js version manager, browser dev tools, and design tokens, there are dozens of files that define how you work. Lose any one of them and your workflow breaks in subtle, frustrating ways.

The real problem is not any single config file. It is the combination. Your Prettier config needs to match your ESLint config, which needs to match your VS Code settings, which need to reference the right extensions. When you set up a new machine or switch between a desktop and laptop, every piece has to be in place or your code starts looking different, your linter throws false positives, and your team thinks you stopped caring about formatting.

This checklist covers everything a frontend developer should be syncing with ConfigSync. Work through it once, and you will never manually configure a frontend environment again.

VS Code is the default editor for most frontend developers, and your settings go far beyond the defaults. You have carefully tuned format-on-save, configured ESLint to run on file change, set Prettier as the default formatter, and installed dozens of extensions.

The vscode module captures your full editor state, including the list of installed extensions. When you pull on a new machine, it installs each extension via the code --install-extension command. No more scrolling through the marketplace trying to remember which 23 extensions you had.

If you use private registries, scoped packages, or GitHub Packages, your .npmrc contains auth tokens and registry URLs that are essential to your workflow. Losing them means you cannot install dependencies.

Whether you use nvm, fnm, or Volta, your Node.js version manager has configuration that determines which version of Node runs by default. The .nvmrc in your home directory sets the global default, while project-level files pin versions per repository.

ConfigSync tracks your global .nvmrc automatically through the node module. For project-level files, they live in the repo and do not need syncing. But your global default matters: without it, a new machine might default to the wrong Node version and your builds break silently.

Chrome DevTools has exportable settings, but most developers never bother. Network throttling presets, custom device dimensions for responsive testing, and workspace mappings all live in your browser profile. While ConfigSync does not directly capture browser state, you can track exported settings files.

Figma tokens and design system configuration files are another overlooked category. If you use tools like Style Dictionary or Tailwind config generators, those output files should be tracked.

Frontend projects increasingly rely on environment variables: API endpoints, feature flags, analytics keys, and authentication URLs that change between local, staging, and production. These live in .env.local files that are gitignored and easy to lose.

Frontend developers rely on global npm packages and system tools that are easy to forget. Here is a typical set:

Once everything is configured, a single push captures your entire frontend environment:

The next time you sit down at a different machine, configsync pull brings back everything: your editor exactly how you left it, your linter rules, your formatter settings, your Node version, your package manager auth, and every project environment file. No checklist required.