DEV Community: Dmitry Kryaklin

How I made cssnano ~30% faster

Dmitry Kryaklin — Wed, 10 Jun 2026 08:26:49 +0000

Introduction

In 2026 I started contributing to cssnano, the CSS minifier that runs at the end of a lot of build pipelines. If you use PostCSS, there's a good chance it processes your CSS on every production build. I came for a couple of correctness bugs, and then I stayed for performance.

cssnano is an old project. The core plugins carry about ten years of edge cases, and most of that code was written to be correct, not fast. For a minifier that's the right priority. But it also means there's room to make it faster without taking risks.

I had one rule for the whole effort: the output must not change. A minifier that produces different bytes after an "optimization" isn't optimized, it's broken. So every change had to keep all fixtures green and produce the exact same CSS, just in less time.

Results first

I measured the full default preset over a set of real framework CSS files — Bootstrap, Bulma, Foundation, UIkit and others. master is 100% of the current time, lower is faster.

Optimization	Plugin	Time vs master
Skip the selector parser on the common path	`postcss-unique-selectors`	81% (−19%)
Skip processors with nothing to do	`postcss-merge-longhand`	93% (−7%)
Remove an O(N²) dedupe scan	`postcss-discard-duplicates`	93% (−7%)

Together that's about a third off the default preset, and none of it changed the output.

Before the techniques, a few words about how I measured, because it shaped everything else.

How I measured

My previous post was about colordx, and those wins were mostly V8 micro-optimizations. cssnano was a different kind of problem. The wins here come from not doing work you don't need to do, plus fixing one bad algorithm. To find that kind of thing you need a profiler and an honest benchmark.

The profiler is the easy part. Node ships one:

node --cpu-prof --cpu-prof-dir=./prof run-preset.mjs

You open the .cpuprofile, sort functions by self-time, and the hot spots stop being a guess.

The honest benchmark is harder. A dev machine is noisy. Background processes, garbage collection and CPU scheduling all add time to a run, and they never subtract it. So if you report the median of your runs, one noisy stretch pulls the middle value up, and a real improvement can look like a regression. This happened to me: a 7% win showed up as +4% because one of three rounds got unlucky.

The fix is to report the minimum. Noise can only make a run slower than its true compute time, so the fastest sample you observe is the closest one to "the code with nothing in its way". I run each version many times, interleave the baseline and the branch to spread out drift, and then check that min and median agree before I trust the number.

The other thing to watch is what you compare. Measuring a single plugin in isolation makes its win look huge, because you removed everything else from the pipeline. A plugin that is "64% faster in isolation" might be 2% of the real run. So I report the whole-preset number, because that's the one a user actually feels.

Now the techniques.

1. Skip the selector parser on the common path

postcss-unique-selectors deduplicates the selector list of a rule. For example, a, a, b becomes a, b. To do this correctly — including comments, order and whitespace — it runs the full postcss-selector-parser on every rule, then clones and walks each parsed node to build a key for deduplication.

That's a second parser, called once per rule, over the whole stylesheet.

But most rules don't need any of that. A rule with a single selector has nothing to deduplicate. And the parser only earns its cost when there are comments to strip out of the key. Both cases can be detected with a plain string check, before anything is allocated:

function generateUniqueSelector(selectors) {
  // No comma means a single selector; nothing to dedupe or sort.
  if (selectors.indexOf(',') === -1) {
    return selectors;
  }

  const uniqueSelectors = new Map();
  // Without comments the node's own toString is already a usable key.
  const hasComments = selectors.indexOf('/*') !== -1;

  // ...the full parser path only runs from here
}

A comma anywhere, including inside :is(a, b), still falls through to the real parser, so correctness doesn't change. But the common rule — one selector, no comments — now returns after a single indexOf instead of starting a parser.

That guard is three lines, and it's the −19%. The fastest code is the code you can prove you don't have to run.

2. Skip processors with nothing to do

postcss-merge-longhand collapses longhand properties into shorthands. There are four property families: border, column, margin and padding. The original code ran all four processors on every rule:

css.walkRules((rule) => {
  processors.forEach((p) => {
    p.explode(rule);
    p.merge(rule);
  });
});

Each processor walks the rule's declarations on its own. So a rule that only has color and font-size still gets walked four times, looking for borders and margins that aren't there.

Most rules touch one of these families at most. So I scan the declarations once and run only the processors whose family is actually present:

css.walkRules((rule) => {
  let hasBorder = false;
  let hasColumn = false;
  let hasMargin = false;
  let hasPadding = false;

  for (const node of rule.nodes) {
    if (node.type !== 'decl') continue;
    const prop = node.prop.toLowerCase();
    if (prop.startsWith('border')) hasBorder = true;
    else if (prop.startsWith('column')) hasColumn = true;
    else if (prop.startsWith('margin')) hasMargin = true;
    else if (prop.startsWith('padding')) hasPadding = true;
  }

  if (hasBorder)  { borders.explode(rule);  borders.merge(rule);  }
  if (hasColumn)  { columns.explode(rule);  columns.merge(rule);  }
  if (hasMargin)  { margin.explode(rule);   margin.merge(rule);   }
  if (hasPadding) { padding.explode(rule);  padding.merge(rule);  }
});

The processors were already no-ops on rules without a matching property. They would walk, find nothing and return. This change just moves that "find nothing" check into one cheap pass instead of four expensive ones. The output is identical, and the result is −7%.

(I first wrote this with a bitmask. It was a few microseconds faster and much harder to read, so I threw it away. Four booleans say what they mean.)

3. Remove an O(N²) dedupe scan

This is the one that scales.

postcss-discard-duplicates removes duplicate rules. To find duplicates, it walked each rule and, for every rule, scanned all of its preceding siblings looking for one with the same selector:

function dedupeRule(last, nodes) {
  let index = nodes.indexOf(last) - 1;
  while (index >= 0) {
    const node = nodes[index--];
    if (node && node.type === 'rule' && node.selector === last.selector) {
      // ...merge last's declarations into the earlier rule
    }
  }
}

For N rules at the same level, that's an O(N²) scan. And it's quadratic even when there are no duplicates at all. Every rule still scans every rule before it, finds nothing and moves on. A stylesheet with 4000 unique rules pays the full quadratic cost for no benefit.

The fix is the standard one. Group the rules first, then compare only inside a group:

// One linear pass: bucket rules by selector.
let ruleGroups;
for (let i = 0; i < nodes.length; i++) {
  const node = nodes[i];
  if (node.type === 'rule') {
    if (!ruleGroups) ruleGroups = new Map();
    const group = ruleGroups.get(node.selector);
    if (group) group.push(node);
    else ruleGroups.set(node.selector, [node]);
  }
}

// Each rule now only compares against rules that share its selector.
const group = ruleGroups && ruleGroups.get(last.selector);
if (group && group.length > 1) {
  dedupeRule(last, group);
}

A selector that appears once — the common case — does no comparison work. Document order and last-wins behavior are preserved, so the output doesn't change.

On the framework files this is −7%, the same as the merge-longhand win, because those files have modest rule lists. The real difference shows up when the input grows. Here are synthetic stylesheets of N distinct-selector rules, this plugin only, with master at 100%:

Rules (N)	before	after
500	100% (1.69 ms)	71% (1.20 ms)
1000	100% (4.84 ms)	52% (2.52 ms)
2000	100% (13.78 ms)	43% (5.90 ms)
4000	100% (45.16 ms)	28% (12.78 ms)

The speedup grows with N, which is the sign that a quadratic term is gone. master roughly triples per doubling of N, while the new version roughly doubles. On a small file you wouldn't notice. On a large generated stylesheet it's the difference between a blip and a stall.

What didn't help

This is the part most posts skip, and it's the more useful one.

I wrote four more "optimizations" and dropped all of them, because the benchmark wouldn't back them up:

Replacing per-call cache keys. A couple of plugins built keys like JSON.stringify({value, options, browsers}) per declaration, when options and browsers are fixed for the whole pass. Using just value is clearly cheaper, but it moved the whole-preset number by less than the noise. Real, but not measurable.
Avoiding a small array allocation in a hot [a, b, c].includes(type) check. Same story. Looks good in a micro-benchmark, invisible end to end.
Reordering cheap checks before an expensive selector check in merge-rules. Sound in theory, but it tangled the control flow for about 0% on the corpus.
Guarding a regex behind an indexOf so it only runs when the token is present. Textbook, and also noise.

The lesson I keep relearning is that an optimization you can't measure isn't an optimization, it's a risk. Every one of these touched code where a small mistake produces wrong CSS. If the upside is below your noise floor, the honest move is to drop the change. I shipped the three the benchmark could see, and dropped the four it couldn't.

Lessons

The biggest win was three lines that skip a parser. It was a guard, not a clever algorithm. A cheap check that lets you skip expensive work beats a faster version of the expensive work.
Quadratic behavior hides in old code, especially in loops that scan siblings. They were written when stylesheets were small. They cost nothing on small input and everything on large input.
Use the minimum, not the median. Interleave baseline and branch, and make them agree before you trust the number.
Measure the whole pipeline, not one plugin. Isolated numbers are how you fool yourself.
Be willing to drop correct code that doesn't move the needle. In a minifier, "harmless and pointless" is still a liability.

This was a different problem from colordx. There the wins came from understanding V8. Here they came from understanding the workload: what the common input looks like, and how much code runs for nothing on it.

All three changes are now merged into cssnano. The method behind the numbers is simple — run the full default preset over a folder of CSS files and take the minimum across many runs — so it's easy to reproduce on your own files. The code is in the cssnano repo.

How I built the fastest color manipulation library in TypeScript and the optimization techniques I learned

Dmitry Kryaklin — Thu, 30 Apr 2026 21:40:00 +0000

Introduction

In 2026, I started building a color manipulation library called colordx. The frontend ecosystem is moving towards CSS Color 4: OKLCH, OKLab, Display-P3, Rec.2020. Most existing libraries were designed for the sRGB era and bolted modern color spaces on top. I wanted to build something that treats the modern stuff as a first-class citizen.

But the goal I cared about most was performance. Not just "faster than colord" fast. I wanted colordx to be the fastest option in the benchmarks I cared about, and I wanted to actually understand why.

This article is a short list of the optimization techniques that mattered the most. If you are working on a hot-path JavaScript library, I hope at least a few of these are useful.

Results first

Benchmark	colordx	colord	culori	chroma-js	color
Parse HEX → toHsl	38 ns	99 ns	151 ns	294 ns	382 ns
Parse HEX → lighten → toHex	64 ns	176 ns	206 ns	850 ns	1010 ns
Mix two colors	102 ns	759 ns	1230 ns	870 ns	1900 ns
Parse HEX → toOklch	271 ns	—	287 ns	916 ns	534 ns
inGamutP3	202 ns	—	1030 ns	—	—

Now let's get into how.

1. Keep one canonical internal representation

Every Colordx instance stores exactly one thing: an RgbColor object { r, g, b, a }. All conversions go through it.

The reason is V8 monomorphism. The class has a fixed shape, so V8 always sees the same two fields on every method call. A library that stores different color models in different instances ends up with polymorphic inline caches everywhere, and JIT performance drops.

2. Don't use Object.create to skip the constructor

This was the single biggest win. My first version used Object.create(Colordx.prototype) in the internal factory to skip parsing:

private static _make(rgb: RgbColor): Colordx {
  const inst = Object.create(Colordx.prototype);
  inst._rgb = rgb;
  inst._valid = true;
  return inst;
}

It looks clean but it is a trap. ES2022 classes with field declarations have a specific V8 hidden class transition chain. Object.create bypasses the constructor, so the field initialization transitions never fire. The resulting instance has a different hidden class than one created with new Colordx(). V8 sees two shapes flowing into every hot method, ICs go polymorphic, performance dies.

Fix: use a sentinel symbol so the constructor can skip parsing while still going through the proper field transition chain.

const _SENTINEL: unique symbol = Symbol();

constructor(input: AnyColor | typeof _SENTINEL, _direct?: RgbColor) {
  if (input === _SENTINEL) {
    this._valid = true;
    this._rgb = _direct!;
  } else { /* parse */ }
}

private static _make(rgb: RgbColor): Colordx {
  return new Colordx(_SENTINEL, rgb);
}

Around 330 ns → 270 ns on Parse HEX → toOklch. Just from how the object is constructed.

3. Precomputed lookup tables for hex output

toString(16).padStart(2, '0') allocates a string every call. Precompute all 256 possibilities:

const HEX_BYTE = /* #__PURE__ */ Array.from(
  { length: 256 },
  (_, i) => i.toString(16).padStart(2, '0')
);

Three array lookups instead of three string allocations. Borrowed from color-bits.

4. Bitwise hex parsing

parseInt('ff', 16) is slow because it is a general-purpose parser. Exploit the ASCII layout to decode a hex character with two integer ops:

const hexNibble = (c: number): number => (c & 0xf) + 9 * (c >> 6);

Based on Lemire's technique.

5. Reuse a module-level buffer when callers always destructure

rgbToHslRaw is the hot path for lighten, darken, saturate, etc. Every call would allocate a fresh { h, s, l, a } object. But all internal callers immediately destructure the result, so there is no aliasing. So I reuse a single object:

const _hslBuf: HslColor = { h: 0, s: 0, l: 0, a: 0 };

export const rgbToHslRaw = (rgb) => {
  // ...
  _hslBuf.h = hDeg;
  _hslBuf.s = clamp(s * 100, 0, 100);
  _hslBuf.l = clamp(l * 100, 0, 100);
  _hslBuf.a = clamp(round(a, 3), 0, 1);
  return _hslBuf;
};

This works only because the function is internal and I control all callers. I would not expose this pattern in a public API.

6. Avoid closure allocation by hoisting helpers to module level

If a helper function is defined inside another function, V8 creates a new closure object on every call. Hoist it to module level and it is allocated once.

// at module level, not inside hslToRgb
const _hueToRgb = (p: number, q: number, t: number): number => { ... };

7. Inline conversions to avoid intermediate object allocation

rgbToOklch used to call rgbToOklab and destructure the result. The intermediate OklabColor object is pure overhead. Inlining the math saves one allocation per call.

I usually hate duplicated code, but for short, well-tested math the allocation savings are real.

8. Provide *Into siblings for per-pixel work

For 500×500 OKLCH gradient renders (250k pixels per frame), the natural API allocates 500k–1M short-lived 3-tuples per frame. Wall-clock cost is modest, but the GC pressure causes frame hitches during interactive drag.

So every channel function has a sibling that writes into a caller-provided buffer:

export const oklabToLinearInto = (
  out: Float64Array | number[],
  l: number, a: number, b: number
): void => { /* writes out[0/1/2] */ };

On a 250k-pixel chained OKLCH→P3 bench, allocations drop from ~9 MB/iter to ~500 kB/iter. Wall-clock is only ~5% better, but interactive renders become visibly smoother.

I rejected the alternative of a shared module-level buffer (slightly faster in micro-bench, around 10%) because it is non-reentrant and a sharp edge in a public API. gl-matrix and three.js use the out-param pattern for the same reason.

9. DRY the data, not the structure

Once I had both oklabToLinear and oklabToLinearInto, the obvious refactor was to make the allocating version delegate to the *Into version. Looks great. Regressed the *Into path by ~20%.

The reason was V8 polymorphism. External callers pass a Float64Array. The new wrapper passes a plain [number, number, number]. The *Into call site went from monomorphic to polymorphic, V8's speculative optimizations got disabled.

The compromise: keep the math duplicated, but extract the matrix coefficients into module-level consts.

const M1_LR = 0.4122214708, M1_LG = 0.5363325363, M1_LB = 0.0514459929;
// ... 20+ named coefficients ...

export const linearSrgbToOklabInto = (out, lr, lg, lb) => {
  const lv = Math.cbrt(M1_LR * lr + M1_LG * lg + M1_LB * lb);
  // ...
};

export const linearSrgbToOklab = (lr, lg, lb) => {
  const lv = Math.cbrt(M1_LR * lr + M1_LG * lg + M1_LB * lb);
  // ...
};

V8 constant-folds module-level consts, so there is no runtime cost vs inline literals. One source of truth for the data, two monomorphic call sites.

The textbook DRY refactor was wrong here. Sometimes you DRY the data and duplicate the structure.

What didn't help

Equally important: things that looked like they should help but didn't. Save yourself the time.

A 256-entry LUT for toLinear was slower on M4. The FP unit executes Math.pow(x, 2.4) fast enough that array lookup overhead is not worth it. Result is architecture-specific.
Manually inlining toLinear inside rgbToOklch made things worse (~270 ns → ~530 ns). The function got too large for V8 to optimize the body as a single unit.
Inlining normalizeHue as an expression instead of a function call: also slower. V8 optimizes named function call sites independently.

The pattern: V8 is smarter than you about inlining small functions. Trust it until you have a profile that says otherwise.

Lessons

The biggest wins came from understanding V8's hidden class model, not from clever algorithms. Monomorphism is a feature you preserve, not a thing you add later.

Allocations matter more than CPU time on hot paths in modern JavaScript. Wall-clock differences are often small, but GC pressure shows up as frame hitches and unpredictable latency.

DRY is a tool, not a rule. V8 cares about call site shape consistency more than your engineering aesthetics.

Always measure on the hardware you care about. The LUT result on M4 might be different on a Cortex-A53 phone or an older Intel laptop.

If you want to play with the library, there is a playground at colordx.dev, and the source is at github.com/dkryaklin/colordx.

How we automated generating and storing selectors for Cypress

Dmitry Kryaklin — Fri, 25 Mar 2022 11:57:15 +0000

Introduction

In 2021, Bravado grew at a rapid pace: the technical team, the codebase, the complexity of our project, etc. The reliability requirements grew as well. We knew that if we want to increase the speed of development and delivery, we have to adopt a modern solution for tests automation.

By that time, the team already had experience writing different kinds of tests. The current speed of adding new tests left much to be desired, and we wanted to try something new, which could significantly improve the situation. At the end of the year, we decided to adopt the Cypress framework.

Problem

Initial integration with Cypress went smoothly. But when we started writing the first tests in Cypress, we ran into a problem: how we should store selectors for elements. The problem is that selectors for elements are just strings, and we wanted to make sure we have only one source of truth.

We started to create a lot of constants and tried to reuse them in both tests and components. But this solution was slow and created a lot of hassle. So we decided we will just copy selectors in tests. Yes, we lost the advantage of having a single source of truth. But now we can move forward faster.

After some time we ended up having several big objects with a list of selectors for most of the pages:

export const FEED_CLASSES = {
  feedTab: '[data-test=posts_header_filter]',
  poolTitle: '.war-room-post-poll',
  postItem: '[data-test=posts_list_preview]',
  postItemPinnedClass: '.war-room-post-preview-presenter--pinned',
  postItemNewPostIconClass: '.war-room-post-preview-presenter__new-post-icon',
  postItemLinkClass: '.war-room-post-preview-presenter__link',
  postCategory: '[data-test=post_preview_topic]',
  feedIconMobile: 'a[href="/war-room/posts/tab/my_feed"]',
  academyIconMobile: '.user-menu-mobile-main-menu > [href="/academy"]',
  academyIconWeb: '[href="/academy"] > .bravado-right-navigation__item-text',
  jobsIconWeb: '[href="/jobs"] > .bravado-right-navigation__item-text',
  jobsIconMobile: '.user-menu-mobile-main-menu > [href="/jobs/profile"]',
  logIniconMobile: 'a[href="/war-room/posts/tab/my_feed?dynamic_modal=sign-in"]',
  raiting: '[data-test=post_preview_rating]',
  upvoteButton: '[data-test=post_preview_vote_up]',
  downvoteButton: '[data-test=post_preview_vote_down]',
};

We understood that this solution is unstable, the selectors are not standardized, it is very difficult to maintain and we cannot know which selectors are still relevant or not. And more importantly, it was a nightmare to reuse them in different tests. So we needed a better solution if we want to continue to expand tests coverage.

Solution

As technical director, my duties included, among other things, the integration and adoption of Cypress among our teams. I was worried that even with Cypress we couldn't write tests as fast as we wanted. And I started looking for a solution.

After several days of researching various solutions, I could not find the one that was right for us. But I started to realize what exactly I want to achieve: instead of copy-paste selector strings from the main codebase to tests by hand, I wanted to extract all selectors from our codebase automatically so we can reuse them in our specs.

Then we could wrap extracted data in a special wrapper to create JavaScript objects with full TypeScript support. Which would allow us to write tests in a declarative style and to get all benefits from proper program language, like auto completion and type checking. And in theory might allow us to validate tests even without running them, thanks to TypeScript.

e.g. Let's say have a component Header with the template:

<template>
  <div class="header">
    <template v-if="user">
      <button data-test="signin-button">Sign In</button>
    </template>
    <template v-else>
      <span data-test="username-label">Hello, {{ user.username }}!</span>
      <button data-test="logout-button">Logout</button>
    </template>
  </div>
</template>

In an ideal world I wanted to get something like that:

import Header from '/cypress/components/Header.test.ts';

Header.SigninButton().click();
Header.UsernameLabel().click();
Header.LogoutButton().click();

After a discussion with the team, everyone agreed that the idea sounded promising and I decided to build POC. I needed to implement three components on different parts of our app in order to achieve what I wanted:

Write a parser for our components that will extract templates and generate JavaScript objects for selectors;
Write a special wrapper layer between generated selectors and our specs;
Modify the application to add a marker for DOM elements when mounting components and Cypress can find our components;

Parser

Since we are using Nuxt as the main framework (Vue underhood). Every component is standardized by internal agreements and linters. Every component has unique name. The templates inside every component are valid HTML and we can easily parse them. I've used node-html-parser to get a list of nodes with the data-test attribute.

Some nodes were other components so I also wanted to find the relation between components in order to build chain selectors e.g.:

Header.NestedComponent().click();
ConfirmDialog.ConfirmDialogFooter.closeButton().click();

I would like to keep this article short and skip the details of the implementation of this parser. When the code was ready I was able to generate JSON for each of the 700 components with the required information. Unfortunately, it was useless without a wrapper layer.

Wrapper Layer

The plan was to create a function that will receive two parameters: component selector (name) and list of nested nodes and return us a function that we can call and get Cypress.Chainable object.

Here is a very simplified version:

export const BravadoComponent = function AbstractComponentWrapper<T extends Record<string, IBravadoComponent>>(
  this: IAbstractComponentWrapper,
  selector: string,
  nested?: T,
) {
  const cyWrapper = (): Cypress.Chainable => {
    return cy.get(selector);
  };

  return Object.assign(cyWrapper, { selector }, nested);
} as unknown as { new <T>(selector: string, nested?: T): IBravadoComponent & T };

As you can see there is nothing special. But it gives us the full power of TypeScript. TypeScript allows us to use autocomplete and type checking. Moreover, we can validate tests even before running them. In the full version, there are more APIs that still evolving and we adding new functionality constantly.

In order to use our parsed information for each component parser generate ComponentName.test.ts file. Here is an example:

// here is our wrapper layer with related interface
import { IBravadoComponent, BravadoComponent } from '../utils/BravadoComponent';

// fully generated dependencies if the component has nested components
import { IModal, _Modal } from './Modal.test';
import { IBravadoText, _BravadoText } from './BravadoText.test';

// here is a list of nodes extracted from component template
export interface IConfirmDialog {
  '_Modal': IBravadoComponent & IModal;
  '_BravadoText': IBravadoComponent & IBravadoText;
  '_confirmModal': IBravadoComponent;
}

// this generator function trat wraps wrapper layer, we use this generated in other components in order to create a link between components
export const _ConfirmDialog = (selector?: string): IBravadoComponent & IConfirmDialog => {
  return new BravadoComponent<IConfirmDialog>(selector || `[data-test-root-confirmdialog="ConfirmDialog"]`, {
    // for components we use generator function
    '_Modal': _Modal(``),
    '_BravadoText': _BravadoText(``),
    // for regular HTML nodes we use wrapper layer with passing selector
    '_confirmModal': new BravadoComponent(`[data-test="confirm-modal"]`),
  });
};

// this entity we are going to use inside specs
export const ConfirmDialog = _ConfirmDialog();

In order to import those test components in our specs parser script also generates an index.ts file with all generated test components:

export { Logo } from './Logo.test';
export { UnusedComponent } from './UnusedComponent.test';
export { AddToCalendar } from './AddToCalendar.test';
export { AnnoucementModal } from './AnnoucementModal.test';
export { AnnoucementModalContent } from './AnnoucementModalContent.test';
export { AudioPlayer } from './AudioPlayer.test';
export { Author } from './Author.test';
...

Finally, at this point we can start writing some code in our specs using generated test components:

import * as root from 'components/generated';

// equivalent of cy.get('[data-test-root-aboutme="AboutMe"]').should('be.visible');
root.AboutMe().should('be.visible');

// equivalent of cy.get('[data-test-root-academyarticle="AcademyArticle"] [data-test-root-bravadoimage="BravadoImage"]').should('have.length', 5);
root.AcademyArticle._BravadoImage().should('have.length', 5);

// equivalent of cy.get('[data-test-root-aboutyouform="AboutYouForm"] [data-test-root-bravadotextinput="BravadoTextInput"]').type('Hello, world!');
root.AboutYouForm._BravadoTextInput().type('Hello, world!');

And it's fully supported by TypeScript!

Here you can see how it looks like in action:

Application adjustments

Last (but not least) missing piece: we need to make sure our application while rendering components will add components names to root elements. In order to do that I decided to use Vue.mixin. When any component will be mounted on the page it will trigger the next function:

    vue.mixin({
      mounted() {
        try {
          const el = this.$el;
          if (!process.env.isProd && el && el.setAttribute && el.className) {
            const name = this.$options.name;

            if (name && !el.className.includes('v-portal')) {
              el.setAttribute(`data-test-root-${name}`, name);
            }
          }
        } catch (e) {}
      },
    });

As you can see we run this code only in the test and development environment. Moreover, we generate unique data keys since one DOM element can be root for several components.

Results

Because this is just a POC, we decided to adopt these tools only for one team. It is worth mentioning that the adaptation went very quickly because the new approach did not require any additional knowledge. After the first month of integration, we noticed the following improvements (compare with other teams):

Reuse of code;
The speed of adding new tests;
The reliability of tests;
Code maintenance time;

Here is a part of real test in our codebase:

    root.WarRoomPostForm._title().type(POST_TITLE);

    root.BravadoEditor().type(POST_CONTENT);
    root
      .BravadoEditor()
      .contains(USER.username)
      .click();

    root.WarRoomPostTopic().click();
    root.WarRoomTopic().first().click();

    root.WarRoomPostTopicModal._saveButton().click();

    root.WarRoomPostForm._saveButton().click();

    root.Notice._messageBlock().should('be.visible');

Considering the above, we believe this POC is was successful. And we have already begun to plan the next part of the improvements for the 1.0 version.

Here are a few ideas that we want to implement in the near future:

Automatically regenerate components on every commit;
Run TS check for tests before every commit;
Deeply integration with Cypress;
Various API improvements;

We would like to release this as an open-source project in near future. So please stay with us and wait for the update :)

PS. special thanks to my team who supported this project, shared ideas, and helped with testing and API suggestions.