15 - Tooling/Config (React+TS Ecosystem)

Question 1

Deck 15 - Tooling/Config (React+TS Ecosystem) (objective)

Answer 1

Goal: review and debug React+TS tooling like a senior: tsconfig, bundlers, linting, tests, env vars, builds, and dependency hygiene.
You learn: what/why (under the hood), common breakages, and evaluator-grade review wording.
Output style: PASS/PARTIAL/FAIL + 2-3 issues + fix approach.

Question 2

Mental model: what tsconfig controls.

Answer 2

tsconfig controls TypeScript type checking + emit settings.
Why: it defines strictness, module resolution, and what code TS outputs (if emitting).

Question 3

Mental model: bundler vs TypeScript compiler.

Answer 3

Bundler (Vite/Webpack) builds and serves your app.
TS compiler checks types; bundler transpiles (often via esbuild/swc) and may not enforce full type checking unless configured.

Question 4

Mental model: dev server vs production build.

Answer 4

Dev server optimizes for fast reload; production build optimizes for size/perf.
Bugs can appear only in prod (minification, tree-shaking, different env vars).

Question 5

Mental model: module resolution (Node vs bundler).

Answer 5

Resolution strategy impacts how imports are found (paths, extensions, package.json exports).
Misconfig causes ‘module not found’ or wrong entry selection.

Question 6

Mental model: ESM vs CJS (why it matters).

Answer 6

ESM uses import/export; CJS uses require/module.exports.
Mixing can break tooling; bundlers handle it but some libs/configs are sensitive.

Question 7

Mental model: dependency graph + lockfile.

Answer 7

package.json declares direct deps; lockfile pins transitive deps.
Lockfile changes can alter runtime even if your code did not change.

Question 8

Mental model: tree-shaking (high level).

Answer 8

Bundlers remove unused exports when code is ESM and side-effects are known.
Poorly structured imports can prevent tree-shaking and bloat bundles.

Question 9

Mental model: source maps (why you care).

Answer 9

Source maps map bundled code back to original sources.
Essential for debugging production errors and stack traces.

Question 10

Mental model: environment variables are build-time in the browser.

Answer 10

Client env vars get baked into the bundle.
Never put secrets in client env vars; treat them as public.

Question 11

Mental model: lint vs typecheck vs tests.

Answer 11

Lint: style/some correctness. Typecheck: TS compile-time safety. Tests: runtime behavior.
All three catch different classes of issues.

Question 12

Mental model: transpilation does not equal type safety.

Answer 12

esbuild/swc can transpile TS without type checking.
Senior: ensure CI runs tsc –noEmit (or equivalent) to enforce types.

Question 13

Mental model: hydration/SSR differences (tooling angle).

Answer 13

SSR requires consistent render output; some libraries behave differently on server.
Config (target, polyfills) can affect runtime compatibility.

Question 14

Mental model: browser targets affect output.

Answer 14

Build targets control what syntax/polyfills are emitted.
Wrong targets can break older browsers or bloat bundles unnecessarily.

Question 15

Mental model: workspace/monorepo tooling risk.

Answer 15

Multiple packages can create version mismatches and duplicate deps.
Review peerDeps and ensure single React version to avoid hooks errors.

Question 16

Mental model: why ‘Invalid hook call’ happens.

Answer 16

Common causes: multiple React copies, mismatched react/react-dom versions, or improper bundling.
Tooling review: check lockfile and dependency tree.

Question 17

Mental model: bundler plugins are code execution.

Answer 17

Plugins run during build; they can introduce security and stability risks.
Prefer trusted plugins and pin versions.

Question 18

Mental model: config changes can be breaking changes.

Answer 18

tsconfig/eslint/vite config changes can change behavior without touching app code.
Reviewer: demand rationale and ensure CI proves safety.

Question 19

Mental model: why CI parity matters.

Answer 19

Local builds can differ from CI due to Node version, env vars, or caching.
Pin Node versions and keep scripts deterministic.

Question 20

Mental model: minimize build-time magic.

Answer 20

Complex config increases fragility.
Senior: keep config small, documented, and tested in CI.

Question 21

tsconfig: strict mode (why).

Answer 21

strict enables many safety checks (nulls, implicit any, etc.).
Senior: treat strictness as correctness; relax only with explicit, justified exceptions.

Question 22

tsconfig: strictNullChecks (impact).

Answer 22

Forces you to handle null/undefined explicitly.
Prevents runtime crashes in React (data loads asynchronously).

Question 23

tsconfig: noImplicitAny (impact).

Answer 23

Prevents implicit any from spreading.
Senior: reduces type holes that cause runtime errors.

Question 24

tsconfig: noUncheckedIndexedAccess (why useful).

Answer 24

Indexing returns T | undefined.
Prevents ‘cannot read property’ bugs when keys are missing.

Question 25

tsconfig: exactOptionalPropertyTypes (what it changes).

Answer 25

Distinguishes 'prop?: T' from 'prop: T | undefined' in assignability. Can surface subtle optional prop bugs; adopt with care.

Question 26

tsconfig: jsx setting (react-jsx).

Answer 26

Modern React uses jsx: react-jsx. Why: no need to import React for JSX in newer setups (depending on tooling).

Question 27

tsconfig: lib and DOM types.

Answer 27

Include 'DOM' lib for browser APIs. Wrong lib config can break types for fetch, URL, etc.

Question 28

tsconfig: moduleResolution (bundler/node).

Answer 28

Controls import resolution. Mismatch with bundler can cause typecheck success but runtime failure (or vice versa).

Question 29

tsconfig: baseUrl/paths (pitfall).

Answer 29

Paths aliases require bundler config too. If only TS knows paths, runtime imports fail.

Question 30

tsconfig: isolatedModules (why).

Answer 30

Required for transpilers that compile file-by-file. Catches patterns that break isolated transpilation.

Question 31

tsconfig: skipLibCheck (tradeoff).

Answer 31

Speeds builds by skipping type checking of .d.ts. Can hide dependency type issues; often acceptable but know the tradeoff.

Question 32

tsconfig: incremental (benefit).

Answer 32

Speeds repeated typechecks by caching. Useful in CI for large repos if cache persists.

Question 33

tsconfig: target (impact).

Answer 33

Controls emitted JS syntax. Too low increases bundle size; too high can break older browsers.

Question 34

tsconfig: module (ESNext).

Answer 34

Bundlers prefer ESNext for better tree-shaking. Let bundler handle final format.

Question 35

tsconfig: noEmit for apps (pattern).

Answer 35

In many React apps, bundler handles emit. Run 'tsc --noEmit' in CI to enforce type safety.

Question 36

tsconfig: types / typeRoots pitfalls.

Answer 36

Overriding types can hide global typings. Be cautious; ensure needed types (jest, node) are included only where appropriate.

Question 37

tsconfig: separate configs for app vs tests (pattern).

Answer 37

Use tsconfig.app.json and tsconfig.test.json. Why: different globals and module systems; reduces conflicts.

Question 38

tsconfig: resolveJsonModule (when).

Answer 38

Allows importing JSON. Use carefully; treat JSON as data, and validate if untrusted.

Question 39

tsconfig: allowJs/checkJs (when).

Answer 39

Useful during migration from JS. checkJs adds type checking to JS files; can increase noise if enabled without plan.

Question 40

tsconfig: downlevelIteration (when needed).

Answer 40

Needed for correct iteration semantics when targeting older JS. Rare for modern browser targets but appears in some setups.

Question 41

Vite vs Webpack (high level).

Answer 41

Vite uses native ESM in dev and bundles for prod; fast HMR. Webpack is highly configurable and widely used; often heavier to tune.

Question 42

Common Vite config pitfalls.

Answer 42

1) path aliases not mirrored in tsconfig 2) env vars prefix rules 3) SSR vs client differences 4) dependency optimization issues.

Question 43

Env vars in Vite (rule).

Answer 43

Client env vars must start with VITE_. Never store secrets; assume anything in client bundle is public.

Question 44

CRA vs Vite migration risk areas.

Answer 44

Differences in env var naming, polyfills, Jest config, and import handling. Ensure scripts and CI typecheck/test steps remain equivalent.

Question 45

ESLint + TypeScript (best practice).

Answer 45

Use @typescript-eslint. Avoid conflicting rules between ESLint and TS; run lint in CI.

Question 46

Prettier vs ESLint (division of labor).

Answer 46

Prettier handles formatting; ESLint handles correctness/style rules. Avoid fighting tools; use eslint-config-prettier if needed.

Question 47

Husky/lint-staged (workflow).

Answer 47

Runs checks pre-commit. Good for hygiene, but keep it fast; do heavy checks in CI.

Question 48

Jest vs Vitest (high level).

Answer 48

Vitest is Vite-native and fast; Jest is widely used with a mature ecosystem. Match tooling to build system and team needs.

Question 49

RTL config: jsdom vs browser reality.

Answer 49

jsdom simulates DOM but not layout/paint. Avoid tests that rely on real layout; use e2e tests for that.

Question 50

Test flakiness sources.

Answer 50

Timers, network, async waiting, global state leakage. Fix: deterministic mocks, fake timers carefully, and clean up between tests.

Question 51

MSW (why used).

Answer 51

Intercepts network requests at runtime for tests/dev. Encourages realistic API mocks and reduces brittle mocking.

Question 52

Source maps in production (tradeoff).

Answer 52

Helps debugging but can expose source. Use hidden source maps or restrict access when needed.

Question 53

Bundle analysis (why).

Answer 53

Identify big dependencies and code-splitting opportunities. Use analyzer tools to confirm improvements.

Question 54

Code splitting (when).

Answer 54

Split routes or heavy components. Avoid over-splitting that harms UX (waterfalls).

Question 55

Polyfills (modern approach).

Answer 55

Prefer targeting modern browsers when possible. If supporting older browsers, add polyfills intentionally and document.

Question 56

Gotcha: relying on bundler to typecheck.

Answer 56

FAIL - Some bundlers transpile TS without type checking. Add 'tsc --noEmit' (or equivalent) to CI to enforce types.

Question 57

Gotcha: path aliases only configured in tsconfig.

Answer 57

FAIL - Typecheck passes but runtime import fails. Mirror aliases in bundler config and verify via production build.

Question 58

Gotcha: secrets in client env vars.

Answer 58

FAIL - Client env vars are public. Move secret to server/secret store; only expose non-sensitive config in client.

Question 59

Gotcha: disabling strict to 'fix' errors.

Answer 59

PARTIAL - Reduces safety. Prefer fixing types; if unavoidable, scope exception and document rationale.

Question 60

Gotcha: skipLibCheck hides dependency type errors.

Answer 60

PARTIAL - Acceptable for speed sometimes, but it can mask issues. Consider enabling for release branches or when debugging types.

Question 61

Gotcha: duplicate React versions -> invalid hook call.

Answer 61

FAIL - Multiple React copies break hooks. Deduplicate and align react/react-dom versions; inspect lockfile and npm ls react.

Question 62

Gotcha: major dependency upgrade with no plan.

Answer 62

FAIL - Major bumps can break runtime. Require CI green, smoke tests, and changelog review for breaking changes.

Question 63

Gotcha: enabling exactOptionalPropertyTypes without rollout plan.

Answer 63

PARTIAL - Can cause widespread assignability changes. Roll out gradually and fix call sites with explicit undefined handling.

Question 64

Gotcha: ESLint and Prettier fighting.

Answer 64

PARTIAL - Tool conflict wastes time. Use eslint-config-prettier and keep formatting in Prettier.

Question 65

Gotcha: flaky tests due to missing awaits.

Answer 65

FAIL - Async UI updates require findBy/waitFor and userEvent.setup(). Missing awaits causes flakes.

Question 66

Gotcha: using jsdom for layout assertions.

Answer 66

PARTIAL - jsdom lacks real layout/paint. Use e2e tests for layout/visual checks.

Question 67

Gotcha: prod-only bug from minification/tree-shaking.

Answer 67

PARTIAL - Reproduce with production build. Ensure sideEffects flags and imports are correct; avoid relying on import side effects.

Question 68

Gotcha: shipping source maps publicly unintentionally.

Answer 68

PARTIAL - Consider hidden source maps or access control. Balance debugging needs with IP exposure.

Question 69

Gotcha: CI Node version mismatch.

Answer 69

FAIL - Pin Node version (engines/.nvmrc) and match CI. Differences can break builds and lockfiles.

Question 70

Gotcha: mixing ESM/CJS incorrectly.

Answer 70

PARTIAL - Can break tooling. Align package.json type, config file extensions, and module settings.

Question 71

Mini-drill: verdict on missing typecheck in CI.

Answer 71

FAIL - Pipeline does not enforce type safety. Add 'tsc --noEmit' to CI and treat type errors as blockers.

Question 72

Mini-drill: reviewer wording for secrets in env.

Answer 72

FAIL - Client env vars are public. Move secrets server-side; expose only public config.

Question 73

Mini-drill: reviewer wording for alias mismatch.

Answer 73

FAIL - Aliases work in TS but not at runtime. Mirror in bundler config and verify with a production build.

Question 74

Mini-drill: reviewer wording for strictness change.

Answer 74

PARTIAL - Lowering strictness reduces correctness guarantees. Prefer fixing types; if necessary, scope and document the relaxation.

Question 75

Mini-drill: reviewer wording for dependency bump.

Answer 75

SUGGESTION: Please note rationale (security/feature), link changelog, confirm CI + smoke tests, and call out any major version bumps.

Question 76

Mini-drill: why tsc --noEmit matters if build works.

Answer 76

Because transpilation can succeed while type assumptions are wrong. Type errors often become runtime bugs in async React flows.

Question 77

Mini-drill: when to split tsconfig.

Answer 77

Split when app/tests need different globals/module systems (DOM vs node, jest/vitest globals). Avoid polluted global types.

Question 78

Mini-drill: what to check for invalid hook call.

Answer 78

Check duplicate React installs, mismatched versions, and monorepo duplication. Inspect lockfile and run npm ls react.

Question 79

Mini-drill: what to ask for on config PR.

Answer 79

Ask for rationale, impacted scripts, CI evidence (build/typecheck/test), and dev workflow notes. Keep config diffs minimal.

Question 80

Mini-drill: quickest triage for 'module not found'.

Answer 80

Check path/case sensitivity, tsconfig paths vs bundler aliases, package.json exports, and lockfile integrity. Re-run clean install.