DEV Community: Denner Vidal

Even a mechanical migration deserves a spec

Denner Vidal — Tue, 10 Nov 2026 16:00:00 +0000

Swapping Jest for Vitest is a mechanical migration. I still wrote a spec before touching a single test.

The reason was simple: the design system already ran on Vite (Storybook included), and Jest with ts-jest kept a second transform pipeline alive just for tests. Consolidate, and get faster.

The spec had three parts.

Inventory. 68 test files. jest.fn in about 120 places across 30 files. jest.mock in 15. Fake timers in exactly one file. toBeInTheDocument used 219 times. I knew exactly what would break.

Non-goals. No migrating legacy packages that have no tests. No root-level Vitest config until a second package gets tests. No swapping jsdom for happy-dom. And no behavior changes in the tests, only jest.* becoming vi.*.

Definition of done. All 68 files passing with the same assertions, pnpm test and CI working unchanged, and five dependencies removed: jest, ts-jest, jest-environment-jsdom, @types/jest and ts-node.

Result: one day of spec, one day of migration, five small, reviewable commits.

The part that protects you most is the non-goals list. A mechanical migration turns into a rewrite the moment someone thinks "while I'm here...".

What was the last "simple" migration that grew on your team?

Monorepo tooling is a maintenance decision, not a technical one

Denner Vidal — Sun, 08 Nov 2026 19:30:00 +0000

Monorepo tooling isn't a technical decision. It's a maintenance decision.

In 2024 I migrated our design system monorepo from Lerna to Lerna Lite. The diff was small in the packages and huge in the lockfile: 3,568 lines added, 11,647 removed. The reason: full Lerna was heavy, and all we used was publish automation and the changelog. Worse, it didn't work with pnpm's workspace: protocol. Without it, internal dependencies were pinned to fixed versions in package.json (cortex-react pointed to cortex-core 0.3.1), and a package from our own repo got downloaded from npm again. With Lerna Lite everything became workspace:*: local packages during development, and the real version written in at publish time. Along the way, yalc and the lerna run scripts went away, replaced by pnpm --filter.

Two years later, a different kind of debt: seven packages repeating the same dependency versions. I moved everything to the pnpm catalog. Today that's 23 dependencies declared in a single file, and every package.json points to catalog:.

In the same commit I added an AGENTS.md at the root and one in every package (eight in total), explaining what the package does and how to run it. It helps new teammates and coding agents alike.

As a tech lead I learned to change the question. Instead of "what's the best tool?", I ask: "who will understand this a year from now, without me?"

In mentoring, that's the criterion I try to pass on: measure a tool by what it costs the next person.

Which tooling decision would you make differently today?

Rollup to Rolldown without breaking the build contract

Denner Vidal — Sat, 07 Nov 2026 22:28:34 +0000

Swapping a bundler is easy. Knowing what you promised your consumers is the hard part.

I migrated two packages of our design system (cortex-core and cortex-react) from Rollup to Rolldown. Before touching the tool, I wrote down the output contract:

ESM with preserveModules in dist/esm
types generated by tsc in dist/types
default.css copied at the end of the build

All of it stayed the same. Rolldown's config API is Rollup-compatible and the copy plugin's buildEnd hook still works. The two config files went from 42 and 45 lines down to 18 and 28.

Two decisions worth recording: I dropped the CJS output, since both packages were already ESM-only, and I now clean dist before building so a stale artifact never gets published.

The cost showed up 13 days later: the mobile Storybook stopped rendering with the new bundle's external packages, and the fix touched the Rolldown configs and added a browser shim to the React Native playground.

Lesson: the contract I wrote covered whoever consumes the library, but not whoever consumes the bundle inside our own playground.

When you change a build tool, which consumer do you forget to list?

Commit message as a mini-RFC

Denner Vidal — Thu, 22 Oct 2026 20:04:04 +0000

The best place to teach a junior engineer to think isn't a meeting. It's the commit message.

A recent commit of mine has three parts, no template:

Problem: portal-based components render into the body and leak styles in Shadow DOM hosts.
Approach: an optional, additive provider, no behavior change for anyone who doesn't use it.
Out of scope: Uploader/Modal, since no consumer has asked yet.

That answers the three questions git blame will ask six months from now: why it changed, why this way, and why the rest didn't.

For people early in their careers, the third part is the most valuable. Saying what you did NOT do shows scope was a decision, not an accident.

In mentoring, I stop commenting on the code and start asking: "what's out of scope here?"

Which review question has changed the way your team writes the most?

PortalProvider and Shadow DOM

Denner Vidal — Tue, 20 Oct 2026 15:56:47 +0000

Your popup escaped the Shadow DOM. And the obvious fix broke the host page.

We ship a portal menu as a UMD web component embedded in JSF apps. FloatingPortal-based components (Tooltip, Select, Autocomplete, PhoneInput) render into document.body by default, which is outside the shadow root, so unstyled.

The workaround was injecting a global stylesheet. Side effect: the whole Tailwind preflight leaked onto the host page and clobbered PrimeFaces and Bootstrap inputs.

The fix is an optional PortalProvider. Each component takes a root prop; if omitted it uses the nearest provider's root; with no provider it falls back to document.body. Nothing changes for anyone who doesn't opt in.

export const useResolvedPortalRoot = (root?: PortalRoot) => {
  const portalRoot = usePortalRoot();
  // undefined = herdar do provider; null = opt-out explícito
  return root === undefined ? portalRoot : root;
};

The detail that matters most: root={null} has to mean "ignore the provider". With root ?? portalRoot, null collapses into the fallback and the escape hatch is gone. So undefined and null behave differently on purpose.

I left Uploader/Modal out on purpose. They still use createPortal, no consumer asked for it, and the fix pattern is different.

Have you ever had to decide whether null means "I don't know" or "I don't want it" in a component API?