Tooling
47 bites tagged Tooling — interview questions with model answers, and 60-second explainers.
Cost of console.log and production-safe debugging
Each console.log serializes data and, when devtools are attached, crosses the bridge synchronously, blocking the JS thread; strip logs in release and use Flipper, dev tools, or remote crash and analytics tools. Debug logging cost.
Expo managed workflow vs bare React Native
Expo gives fast setup, OTA updates, managed builds, and prebuilt APIs; bare gives full native control and arbitrary native modules. judgment on tooling tradeoffs.
Measure a competitor's public performance
Synthetic audits via Lighthouse and WebPageTest, timed public-API probes, and reading response headers. black-box web performance measurement. proposing scraping or load attacks that break terms of service.
dependencies vs devDependencies in package.json
Dependencies ship and run in production; devDependencies are only for development; omitted with npm install --production. understanding runtime versus build/test tooling.
Automated detection of deprecated component usage
Machine-readable deprecation metadata, AST scanning across repos, scheduled jobs, per-team dashboards and PR-level warnings with codemod links. Deprecation auditing pipeline.
Tracking design system health across the org
Static AST scanning for component imports and props, lint or detect-one-offs, parse package manifests for version drift, aggregate into a dashboard. Adoption metrics and tooling.
Tracking design system component usage and versions
Static scan of code or lockfiles, a central reporting store, and a dashboard; data drives deprecation and roadmap. building adoption telemetry across many apps. only counting npm downloads as real usage.
Tracking design system adoption technically
Scan codebases for component imports via AST, compute adoption versus off-system usage, and aggregate into a dashboard over time. Whether you can instrument adoption with real data.
Monorepo vs polyrepo for a design system
Atomic cross-package changes and shared tooling versus build orchestration, caching, and versioning complexity. repo architecture trade-offs. blanket pro or anti stance ignoring release and CI implications.
Storybook's role in design system infrastructure
Isolated development, living documentation, visual and interaction testing, shared review surface. why a component explorer matters. describing it only as a dev playground with no testing or docs value.
Publishing a component to a private NPM registry
Configure package.json fields and scoped name, build dist, set registry auth, npm publish with access restricted. the packaging-to-publish workflow. forgetting the build step or shipping raw source.
Auto-generating component API docs from source
Extract types via react-docgen-typescript, surface in Storybook ArgsTable, enrich with JSDoc. keeping prop docs in sync with code. maintaining a hand-written prop table that silently drifts.
Automated Release Pipeline
An automated release pipeline turns merged design-system changes into published, versioned packages without manual steps, using semantic versioning and changelogs so consumers can upgrade safely and the team ships small changes frequently and reliably.
Python Virtual Environments
A virtual environment is an isolated Python installation with its own packages, so each project gets the exact dependency versions it needs without conflicting with other projects or the system Python.
Monorepo tradeoffs for a design system
Monorepos give atomic cross-package changes, shared tooling, and easy local linking; drawbacks include build complexity, CI scaling, and tighter coupling. build/repo architecture judgment.
CSS Modules versus BEM for encapsulation
CSS Modules scope via build-time hashed class names automatically; BEM scopes via disciplined human naming with no tooling. understanding of scoping strategies.
Transforming tokens for multiple platforms
A transformer like Style Dictionary parses JSON, applies platform transforms, and renders formatted outputs (CSS vars, Swift, Kotlin) via configured platforms. knowledge of token build pipelines.
Why design systems use Sass or PostCSS
Sass adds variables, nesting, mixins, and functions for reuse; PostCSS transforms CSS via plugins like autoprefixer. Knowing what preprocessors add over plain CSS. claiming native CSS variables make them entirely obsolete.
Build a custom PostCSS plugin (px to rem)
Export a plugin returning visitor hooks, walk Declaration nodes, parse and rewrite px values to rem against a base size. PostCSS as an AST transformer. treating CSS as a regex string, not a parsed tree.
What does autoprefixer do and why?
Autoprefixer is a PostCSS plugin that adds vendor prefixes to CSS based on a browserslist target using compatibility data, so you write standard CSS and it handles support. cross-browser CSS tooling.
What is PostCSS and how it differs from Sass
PostCSS is a plugin-driven tool that parses CSS into an AST and transforms it; it is not a fixed language like Sass but a platform for plugins like autoprefixer. understanding CSS tooling architecture.
What is a CSS pre-processor?
A pre-processor adds variables, nesting, mixins, functions, and partials, compiling its own syntax into plain CSS for the browser. basics of authoring tooling.
Measuring design system adoption and health
Component coverage and version spread from code scans, usage analytics, issue and satisfaction signals. quantifying adoption with concrete, automatable metrics.
Kotlin 2.4.0 Ships Stable Context Parameters and UUID API
Kotlin 2.4.0 ships stable context parameters, a built-in UUID API, and Java 26 support. Context parameters replace manual dependency threading through call chains.
Get Tooling bites daily.
Five a day, five minutes, offline. With quizzes so it sticks.
Open testing — you’ll join as an early tester.