DEV Community: Vadim Vinogradov

Old Angular project with Claude Code

Vadim Vinogradov — Fri, 13 Mar 2026 17:24:02 +0000

This is a common friction point with Angular projects: Claude Code will run Jest instead of Karma even if you have karma.conf.js. Why? Because most of the training data and community content from recent years skews heavily toward Jest (or Vitest) as the replacement.

So Claude Code's "prior" is that a modern JS/TS project uses Jest. Outside Angular <17, virtually nobody uses Karma anymore. Claude Code doesn't have deep framework-specific heuristics — it pattern-matches across all JS/TS projects, and Jest dominates that distribution overwhelmingly.

What we can do to steer it: in your project/CLAUDE.md file, write something like:

This project uses Karma + Jasmine for unit tests. Run tests with ng test or npx karma start. Do not use Jest.

Happy coding!

Stop Running Prettier Through ESLint — Here's Why Standalone Is Better

Vadim Vinogradov — Mon, 02 Mar 2026 11:48:12 +0000

If you've set up a JavaScript project in the last few years, there's a good chance you're running Prettier through eslint-plugin-prettier. It was the go-to approach for a while — one tool, one command, one unified set of squiggly red lines in your editor. Simple, right?

Here's the thing: the Prettier team themselves recommend against it. And once you understand why, you'll probably want to change your setup too.

Prettier Formats Way More Than JavaScript

ESLint is a JavaScript (and TypeScript) tool. That's its world. When you run Prettier as an ESLint plugin, Prettier is confined to that world — it only gets invoked on files that ESLint processes.

But Prettier natively supports a much broader set of languages:

CSS, Less, and SCSS
HTML
JSON
YAML
Markdown (including MDX)
GraphQL
Vue and Angular templates
Handlebars

That package.json with inconsistent indentation? The .yaml config where someone mixed tabs and spaces? The CSS file with wildly different formatting conventions? ESLint never touches those. If Prettier only runs as an ESLint plugin, those files stay messy.

When you run Prettier standalone — via CLI, editor integration, or a pre-commit hook — a single prettier --check . or prettier --write . will catch formatting inconsistencies across all of these file types in your project, not just the ones ESLint knows about.

This is especially impactful in real-world projects. Think about how many non-JS files live in a typical repository: CI configs in YAML, style sheets, JSON data fixtures, Markdown documentation. Formatting consistency across all of them matters, and standalone Prettier gives you that for free.

It's Faster

This isn't just anecdotal — it's documented by the Prettier team on their official integration guide:

[Prettier plugins run inside linters] are slower than running Prettier directly.

Now, to be clear — both approaches parse your JS/TS files twice. Whether Prettier runs as a plugin or standalone, ESLint parses the file and Prettier parses the file. That part is the same.

The performance difference comes from the integration overhead. When Prettier runs as an ESLint plugin, there's an entire middle layer doing extra work for every file: it runs Prettier, diffs the formatted output against the original, then converts every formatting difference into an ESLint diagnostic object complete with line numbers, column offsets, and fix ranges. ESLint then processes all of those diagnostics through its reporting and auto-fix pipeline. That's a lot of machinery just to change a semicolon.

Standalone Prettier skips all of that. It parses, formats, writes. No diffing, no diagnostic generation, no round-tripping through a linter's fix system. On a large codebase or in CI, that overhead adds up.

The Red Squiggly Problem

There's a subtler UX argument the Prettier docs also make: when Prettier runs as a linter rule, every formatting issue shows up as a lint error. Your editor fills with red and yellow underlines for things like trailing commas and bracket spacing — things that Prettier will auto-fix on save anyway.

The whole point of Prettier is to stop thinking about formatting. You write code however you want, hit save, and it snaps into place. Treating formatting deviations as lint errors defeats that purpose. It adds cognitive noise instead of removing it.

With standalone Prettier, formatting happens silently via your editor's format-on-save or a pre-commit hook. The only time you hear from Prettier is when you explicitly run --check in CI — and that's just a pass/fail gate, not a wall of warnings in your editor.

The Recommended Setup

The Prettier docs lay out a clean separation of concerns:

Prettier handles formatting: indentation, line length, semicolons, quotes, trailing commas — the stuff that doesn't affect how your code runs.

ESLint handles code quality: unused variables, unreachable code, implicit globals, potential bugs — the stuff that does matter for correctness.

To prevent them from fighting, install eslint-config-prettier. It disables all ESLint rules that would conflict with Prettier, so the two tools stay in their lanes.

A typical setup looks like this:

# Install both
npm install --save-dev prettier eslint eslint-config-prettier

Add prettier to the end of your ESLint config's extends array (Flat Config shown):

import eslintConfigPrettier from "eslint-config-prettier";

export default [
  // ...your other configs
  eslintConfigPrettier,
];

Then create your .prettierrc:

{
  "semi": true,
  "singleQuote": true,
  "trailingComma": "all",
  "printWidth": 80
}

Now run them separately:

# Check formatting across your ENTIRE project
npx prettier --check .

# Auto-fix formatting
npx prettier --write .

# Lint for code quality
npx eslint .

Or better yet, add both to your CI pipeline and a pre-commit hook (with lint-staged):

{
  "lint-staged": {
    "*": "prettier --write --ignore-unknown",
    "*.{js,ts,jsx,tsx}": "eslint --fix"
  }
}

Notice the * glob for Prettier — it runs on everything, while ESLint is scoped to JS/TS files. That's the whole point.

TL;DR

	Prettier via ESLint Plugin	Prettier Standalone
File coverage	Only JS/TS (whatever ESLint processes)	CSS, JSON, YAML, Markdown, HTML, GraphQL, and more
Speed	Slower (double parsing)	Faster (direct formatting)
Editor noise	Red squiggly lines for formatting	Silent format-on-save
Recommended by Prettier	No	Yes

If you're still running eslint-plugin-prettier, consider pulling Prettier out and letting it run on its own. You'll get broader coverage, faster runs, and a quieter editor. And you'll be following the approach the Prettier team actually recommends.

WebStorm vs VSCode

Vadim Vinogradov — Tue, 23 Sep 2025 20:19:01 +0000

As a long-time WebStorm user trying to migrate to VSCode (mainly because VSCode seems to integrate better with modern AI tools and extensions), I quickly noticed some differences—especially around Git conflict resolution. While VSCode is powerful and extremely customizable, there are still areas where WebStorm offers a smoother, more feature-rich experience out of the box.

Merging Git Conflicts

In WebStorm, conflict resolution feels more granular. You can manage each line individually:

In VSCode, the built-in merge editor works differently. It highlights conflict sections and provides options like “Accept Current,” “Accept Incoming,” “Accept Both,” or “Compare Changes.” However, it applies the choice to the whole conflict block, not line by line. This is faster for simple cases, but less precise if you want fine-grained control:

Viewing Which Files Had Conflicts

After resolving a merge, it’s often useful to double-check which files originally had conflicts—especially when reviewing your work or collaborating on complex merges.

In WebStorm, this is straightforward. The Git log not only shows merge commits but also clearly highlights which files had conflicts during that merge:

In VSCode, you can see the list of files changed in a merge commit, but not specifically which ones had conflicts. Even with GitLens, the UI focuses on “modified vs added vs deleted” files. Conflict status isn’t preserved in the UI, so you lose that bit of insight after the merge is completed:

CSS

Right now, there is no VS Code extension that lets you click on a CSS selector and directly see all its Angular usages (like WebStorm does). Closest you get is CSS Peek + manual search. (Update: CSS Navigation extension can do CSS -> HTML find references).

Frontend Monitoring and Error Tracking

Vadim Vinogradov — Mon, 12 Feb 2024 16:33:10 +0000

Selecting an error tracking and reporting service is not always easy. There are three main criteria for good error-tracking software:

ability to group similar stack traces into one entity
support for source maps (because your stack traces will likely be minified)
ability to export stack traces

Let's take one popular example of such systems, Sentry.io, and a couple of corporate-level ones: AWS CloudWatch RUM and Splunk RUM.

Sentry.io:

Error grouping	Source maps	Notifications	Self-Hosted	Export
✅	✅	✅	✅	❌

AWS CloudWatch RUM:

Error grouping	Source maps	Notifications	Self-Hosted	Export
✅	❌	❌	❌	✅

Error grouping:

No source maps:

Splunk RUM:

Error grouping	Source maps	Notifications	Self-Hosted	Export
❌	❌	❌	❌	✅

No error grouping:

No source maps:

But Splunk RUM has strong features for tracking user actions step-by-step:

CloudWatch RUM and Spunk RUM are not focused on error tracking only, and they don't have notifications about errors. You need some extra time and skill to configure them (this might not be possible).

Launch WebStorm from terminal or Finder folder by shortcut in MacOS

Vadim Vinogradov — Mon, 10 Jan 2022 00:53:22 +0000

Simple tutorial on how you can quickly run WebStorm (or any JetBrains Intellij Idea) from Finder in MacOS

Comparing frontend libraries

Vadim Vinogradov — Sat, 08 Jan 2022 19:53:52 +0000

I just want to highlight two great services. They provide some very interesting statistics which might help you to choose a library among competitions. If you haven't seen yet go check it out:

https://www.npmtrends.com/:

https://openbase.com/:

Webpack5 + vue3

Vadim Vinogradov — Wed, 05 Jan 2022 11:27:25 +0000

Nevertheless you can create a simple vue app by

npm install --save-dev @vue/cli
vue create vue3-project

but it is too simple. Sometimes we need to be close to bare metal - then we need a custom build with our own webpack.config.js. Reasons you might need that:

you are a skilled webpack user
you have a proven webpack config from a previous project
you want to integrate with some third parties

Here a simple proven webpack.config.js which allows using Single File Components (SFC). Here is a project structure we are going to use:

Features included:

CSS modules
extract node_modules to a separate file (or chunk, or bundle)

webpack.config.js:

const path = require('path');
const HtmlWebpackPlugin = require("html-webpack-plugin");
const MiniCssExtractPlugin = require("mini-css-extract-plugin");
const CssMinimizerPlugin = require('css-minimizer-webpack-plugin');
const { VueLoaderPlugin } = require("vue-loader");
const { CleanWebpackPlugin } = require("clean-webpack-plugin");



const src  = path.resolve(__dirname, 'src');
const dist = path.resolve(__dirname, 'dist');


module.exports = (env, argv) => {
    const IS_PRODUCTION = argv.mode === 'production';

    const config = {
        entry: './src/index.js',
        output: {
            path: dist,
            filename: "[name]-[contenthash].js",
        },

        resolve: {
            alias: {
                "@": src
            }
        },
        mode: argv.mode,
        devServer: {
            static: dist
        },
        plugins: [
            new HtmlWebpackPlugin(),
            new VueLoaderPlugin(),
            new CleanWebpackPlugin(),
        ],
        module: {
            rules: [{
                test: /\.vue$/,
                loader: "vue-loader",
                exclude: /node_modules/
            }, {
                test: /\.css$/,
                use: [
                    IS_PRODUCTION ? MiniCssExtractPlugin.loader : "style-loader",
                    {
                        loader: "css-loader",
                        options: {
                            modules: {
                                localIdentName: "[local]--[hash:base64:6]",
                            },
                        }
                    }
                ]
            }, {
                test: /\.js$/,
                loader: "babel-loader",
                exclude: /node_modules/
            }, {
                test: /\.(png|jpe?g|gif|webm|mp4|svg)$/,
                loader: "file-loader",
                options: {
                    outputPath: "assets"
                }
            }]
        },
        optimization: {
            minimizer: [
                // extend default plugins
                `...`,
                // HTML and JS are minified by default if config.mode === production.
                // But for CSS we need to add this:
                new CssMinimizerPlugin()
            ],
            splitChunks: {
                cacheGroups: {
                    commons: {
                      test: /[\\/]node_modules[\\/]/,
                      name: 'node_modules',
                      chunks: 'all',
                    },
                },
            },
        }
    };


    if (IS_PRODUCTION) {
        // put all CSS files to a single <link rel="stylesheet" href="...">
        config.plugins.push(new MiniCssExtractPlugin({
            filename: "[contenthash].css"
        }));

    } else {
        // config.devtool = "inline-source-map";
    }

    return config;
}

package.json:

  "scripts": {
    "start": "webpack serve --open --mode=development",
    "build": "webpack --mode=production --progress",
    "dist-clean": "rm -fr dist/*"
  },

Full project https://github.com/vinogradov/webpack-templates/tree/main/webpack5-simple-vue3. Thanks!