Reviewing files that changed from the base of the PR and between f54934b and 7ea742c.

• package-lock.json is excluded by !**/package-lock.json

• src/cartesian/Brush.tsx
• src/cartesian/CartesianGrid.tsx
• src/cartesian/Funnel.tsx
• src/cartesian/Line.tsx
• src/cartesian/ReferenceLine.tsx
• src/cartesian/YAxis.tsx
• src/cartesian/getEquidistantTicks.ts
• src/cartesian/getTicks.ts
• src/chart/RechartsWrapper.tsx
• src/chart/Sankey.tsx
• src/chart/SunburstChart.tsx
• src/chart/Treemap.tsx
• src/component/LabelList.tsx
• src/component/ResponsiveContainer.tsx
• src/component/Text.tsx
• src/component/Tooltip.tsx
• src/polar/Pie.tsx
• src/polar/PolarRadiusAxis.tsx
• src/shape/Curve.tsx
• src/state/cartesianAxisSlice.ts
• src/state/optionsSlice.ts
• src/util/ChartUtils.ts
• src/util/scale/RechartsScale.ts
• storybook/tsconfig.json
• test/cartesian/Area.spec.tsx
• test/cartesian/Bar.spec.tsx
• test/cartesian/Brush.stacked.spec.tsx
• test/cartesian/ErrorBar.spec.tsx
• test/cartesian/Funnel.spec.tsx
• test/cartesian/Scatter.spec.tsx
• test/cartesian/XAxis/XAxis.vertical.spec.tsx
• test/cartesian/YAxis/YAxis.spec.tsx
• test/chart/LineChart.spec.tsx
• test/helper/createSelectorTestCase.tsx
• test/helper/expectStackGroups.ts
• test/helper/toBeRechartsScale.ts
• test/polar/PolarGrid.spec.tsx
• test/state/optionsSlice.spec.ts
• test/state/selectors/pieSelectors.spec.tsx
• test/state/selectors/selectors.spec.tsx
• test/tsconfig.json
• tsconfig.base.json
• tsconfig.json

• test/cartesian/Brush.stacked.spec.tsx
• test/state/selectors/pieSelectors.spec.tsx
• test/state/optionsSlice.spec.ts

• GitHub Check: Build, Test, Pack
• GitHub Check: Analyze (javascript-typescript)

test/state/selectors/selectors.spec.tsx (1)

744-744: LGTM! Explicit generic typing improves type safety.

Adding the <TooltipTrigger> generic parameter provides better type inference for the test callback parameter and aligns with the PR's goal of enabling strict TypeScript checking.

src/component/ResponsiveContainer.tsx (1)

175-179: LGTM! Clean defensive pattern for strict TypeScript.

The null check for entries[0] properly handles TypeScript's strict indexed access (noUncheckedIndexedAccess), where array access returns T | undefined. While the ResizeObserver spec guarantees a non-empty array, this guard satisfies the compiler and adds runtime safety without affecting normal operation.

test/helper/expectStackGroups.ts (1)

71-71: Approve the error type guard pattern.

The change from directly accessing e.message to using e instanceof Error ? e.message : String(e) is the correct approach for TypeScript strict mode, where caught values are typed as unknown. This properly handles both Error objects and other thrown values.

Also applies to: 91-91, 114-114

src/component/Text.tsx (1)

430-432: LGTM! Appropriate null-safety guard for strict TypeScript.

The extraction of firstLine and the explicit null check align well with the strict TypeScript configuration. While the length check at line 406 logically guarantees that wordsByLines[0] exists, this defensive approach correctly handles the noUncheckedIndexedAccess compiler option, which types array access as potentially undefined. The downstream isNumber validation at line 434 provides an additional safety net for the width property.

src/chart/RechartsWrapper.tsx (3)

108-112: LGTM! Defensive guard for strict TypeScript.

The null check for entries[0] is appropriate for strict TypeScript mode and defensive programming, even though the ResizeObserver spec guarantees at least one entry in the callback.

---

187-187: LGTM! Improved type precision.

Refining the forwardRef signature to use StaticDivProps correctly enforces that StaticDiv only accepts numeric width and height values.

---

219-219: LGTM! Cleaner boolean check.

Simplifying to responsive ? ResponsiveDiv : NonResponsiveDiv is more idiomatic since responsive is already a boolean.

src/cartesian/getEquidistantTicks.ts (2)

94-96: LGTM! Appropriate null-safety guard.

The null check prevents potential runtime errors when iterating over ticks that may contain null or undefined entries. Using == null is idiomatic for checking both null and undefined in one condition.

---

132-135: LGTM! Consistent null-safety in result construction.

The null check when building the final ticks array ensures only valid tick entries are returned, maintaining consistency with the earlier null check at lines 94-96.

test/cartesian/ErrorBar.spec.tsx (1)

1263-1265: LGTM! Appropriate use of as const for test data.

The change correctly uses as const (the only permitted type assertion per coding guidelines) to create a readonly tuple with literal types, and removes the explicit parameter type annotation to rely on inference. This simplifies the test while maintaining type safety.

Based on learnings, as const is the only permitted type assertion in TypeScript.

test/polar/PolarGrid.spec.tsx (3)

36-38: LGTM! Improved type safety with explicit SVG element types.

Adding the <SVGLineElement> type parameter to querySelectorAll provides better type inference, eliminating the need for explicit parameter type annotations in the map callback while maintaining type safety.

---

56-59: LGTM! Consistent type-safe pattern for SVG polygons.

The explicit <SVGPathElement> type parameter provides proper type inference while the inline return type annotation maintains clarity about the return value structure.

---

77-80: LGTM! Consistent type-safe pattern for SVG circles.

The explicit <SVGCircleElement> type parameter completes the consistent pattern of type-safe SVG element handling across all three helper functions in this file.

test/chart/LineChart.spec.tsx (1)

494-494: LGTM! Appropriate type broadening for test helper.

Making the properties optional and allowing string | number for coordinates provides flexibility for various test scenarios while maintaining type safety. This aligns with similar test typing improvements across the codebase.

tsconfig.base.json (1)

1-21: LGTM! Comprehensive strict TypeScript configuration.

This base configuration appropriately enables all strict type-checking options, which directly supports the PR objectives of fixing TypeScript problems and enforcing stricter compilation rules. Key highlights:

• strictNullChecks: true - requires the null checks being added throughout the codebase
• noUncheckedIndexedAccess: true - enforces safe array/object property access
• noImplicitAny: true - aligns with coding guidelines to never use implicit any
• useUnknownInCatchVariables: true - enforces using unknown over any in catch blocks

These settings provide the foundation for the type safety improvements throughout this PR.

Based on learnings and coding guidelines, these strict settings enforce never using any type and requiring explicit types.

src/cartesian/getTicks.ts (1)

25-33: LGTM! Excellent null-safety improvements.

The null-safety guards are well-implemented:

• The initialEntry pattern correctly skips null array elements and preserves the original entry for size calculations
• The tail processing is properly guarded with if (tail != null)
• Sign computation safely defaults to 1 when insufficient ticks are available

These changes strengthen the robustness of tick generation without altering the core logic.

Also applies to: 79-95, 100-108, 178-180

test/helper/createSelectorTestCase.tsx (1)

12-12: LGTM! Type simplifications improve test helper flexibility.

The changes correctly loosen the type constraints:

• emptySelector no longer requires the Redux Toolkit Selector type wrapper
• Parameter types in isReactHook and getComp now accept plain state-to-value functions

These adjustments align well with the stricter TypeScript configuration while maintaining type safety in test utilities.

Also applies to: 38-43

test/cartesian/YAxis/YAxis.spec.tsx (1)

1229-1229: LGTM! Correct use of as const for tuple type inference.

The as const assertion appropriately narrows the array to a readonly tuple type, enabling better type inference for the it.each() test parameters. This aligns with the coding guideline that permits as const as the only allowed type assertion.

src/util/ChartUtils.ts (1)

44-62: LGTM! Signature change safely accommodates nullish inputs.

The updated signature obj: T | null | undefined correctly reflects that the function can handle nullish objects. The existing isNullish(obj) guard on line 49 ensures safe handling.

This change strengthens type safety across all call sites and aligns with the PR's strict null-checking improvements.

tsconfig.json (1)

17-17: LGTM! Strict TypeScript mode successfully enabled.

These configuration changes are the culmination of the PR's objective:

• strictFunctionTypes: true enforces stricter function type checking (contravariant parameters)
• noUncheckedIndexedAccess: true makes indexed access return T | undefined, preventing unsafe array/object access

The TODOs referencing issue #6645 are now resolved. The codebase-wide null-safety guards and type refinements throughout this PR ensure compatibility with these stricter compiler checks.

Also applies to: 23-23

test/cartesian/Scatter.spec.tsx (1)

116-118: LGTM!

The optional typing for cx and cy aligns with the stricter TypeScript configuration. SVG attributes handle undefined gracefully, so this is a safe type relaxation for test compatibility.

test/helper/toBeRechartsScale.ts (1)

6-22: LGTM!

The changes improve type safety and correctness:

1. Explicit return type aligns with Vitest's custom matcher contract.
2. The instanceof Error check handles edge cases where non-Error values are thrown.
3. Wrapping errorMessage in a function ensures consistent return structure.

src/polar/Pie.tsx (1)

877-878: LGTM!

The explicit typing and nullish coalescing provide proper null-safety when sectors is empty or startAngle is undefined. This defensive approach aligns with the PR's goal of stricter TypeScript handling.

src/component/Tooltip.tsx (1)

38-40: LGTM!

Using concrete ValueType and NameType instead of generics for the internal defaultUniqBy function is appropriate since it's only used as a fallback within the Tooltip component.

src/polar/PolarRadiusAxis.tsx (1)

267-272: LGTM!

The explicit type annotations for the reduce operation improve type safety and clarity. The tuple typing [number, number] correctly represents the extent calculation.

test/cartesian/Bar.spec.tsx (1)

1263-1267: LGTM!

The test correctly reflects the widened minPointSize callback signature. The null guard value != null && value > 0 properly handles the new nullable parameter type.

test/tsconfig.json (1)

2-9: LGTM!

Extending from tsconfig.base.json ensures consistent TypeScript settings across the project. Disabling noUncheckedIndexedAccess specifically for tests is a pragmatic tradeoff, and the comment documents the reasoning well.

storybook/tsconfig.json (2)

2-2: LGTM – Consolidates TypeScript configuration.

Extending from a shared base config promotes consistency across the project.

---

8-9: Technical debt acknowledged.

The comment explicitly documents why noUncheckedIndexedAccess is disabled for Storybook. This is a pragmatic decision to scope the strictness effort, as the setting only affects Storybook stories and not production code or public API declarations.

src/chart/SunburstChart.tsx (1)

182-187: LGTM – Type signature generalized to match TooltipPayloadSearcher.

The signature now conforms to the broader TooltipPayloadSearcher type (from src/state/tooltipSlice.ts), accepting and returning unknown instead of specific types. The implementation correctly handles the activeIndex null check and delegates to es-toolkit/compat/get, which safely handles unknown data.

test/cartesian/Funnel.spec.tsx (2)

3-3: LGTM – Public API import follows guidelines.

Import from ../../src correctly uses the public API entry point.

---

77-88: LGTM – Type accuracy improved.

The activeShape callback now correctly receives FunnelTrapezoidItem instead of FunnelProps, accurately reflecting the runtime payload type. The properties accessed (x, y, height, upperWidth) align with the FunnelTrapezoidItem definition.

src/cartesian/ReferenceLine.tsx (1)

305-311: LGTM – Adds null-safety for strict TypeScript mode.

Explicit element access with null checks ensures type safety when noUncheckedIndexedAccess is enabled. The destructuring occurs after validation, preventing potential runtime errors.

test/cartesian/Area.spec.tsx (3)

53-61: LGTM – Test types loosened appropriately.

Making index, x, and y optional and widening x/y to string | number accommodates the flexible label API without changing test behavior.

---

73-81: LGTM – Consistent with label render function typing.

The Label component props mirror the loosened types from the render function, maintaining consistency across the test file.

---

89-89: LGTM – Props passed through correctly.

The inline function correctly forwards index, x, and y to the Label component.

src/cartesian/CartesianGrid.tsx (2)

332-334: Good null-safety improvement.

Using an explicit == null check instead of a falsy check (!array[i+1]) is safer here, as 0 is a valid coordinate value that would incorrectly be treated as falsy with the old approach.

---

370-372: Consistent with the HorizontalStripes fix.

Same null-safety improvement applied consistently to VerticalStripes.

src/cartesian/Line.tsx (1)

410-415: Solid null-safety guards in stroke dasharray calculation.

The changes properly guard against potentially undefined array elements:

• Using lines[i] ?? 0 prevents NaN from propagating through the sum
• The explicit lineValue != null check before comparison is safer than relying on implicit coercion

src/cartesian/Brush.tsx (4)

250-260: Appropriate null-safety in binary search.

Guarding middleValue and endValue against null prevents potential runtime errors when accessing array elements that might be undefined (e.g., out-of-bounds access).

---

643-646: Safer touch event handling.

Using optional chaining on changedTouches?.[0] and checking for null before calling handleDrag prevents potential errors when touch events don't have the expected structure.

---

698-700: Consistent early return pattern for null events.

Both handleSlideDragStart and handleTravellerDragStart now properly exit early if the computed event is null, preventing downstream errors when accessing event.pageX.

Also applies to: 745-747

---

836-838: Guard against invalid scale value.

The null check on newScaleValue prevents comparing undefined against endX/startX and setting invalid state.

src/cartesian/YAxis.tsx (2)

2-2: Import is correct.

The isValidElement is properly imported from React and used at line 237. The AI summary incorrectly stated it was removed.

---

209-291: Function declaration style change looks good.

Converting from an arrow function with explicit FunctionComponent<Props> type annotation to a regular function declaration is a valid refactor. The typing is preserved through the PropsWithDefaults parameter type.

test/cartesian/XAxis/XAxis.vertical.spec.tsx (2)

28-69: Good use of as const for type inference.

Using as const on the it.each array preserves the literal types ('category' | undefined), allowing TypeScript to properly infer the axisDomainType parameter type without needing an explicit AxisDomainTypeInput annotation. This is cleaner and more idiomatic.

---

71-73: Consistent typing pattern applied.

Same as const pattern applied consistently to the second test case.

src/component/LabelList.tsx (3)

25-25: Improved payload typing.

Changing from unknown to Record<string, unknown> | null | undefined is more specific and enables better type checking when accessing properties on the payload object.

---

80-80: Good change from any to unknown.

Changing DataKey<Record<string, any>> to DataKey<Record<string, unknown>> aligns with the coding guideline to never use any type and prefer unknown instead.

---

184-184: Safe guard removal.

Removing entry && from the getValueByDataKey call is safe because:

1. entry is guaranteed to exist as we're iterating over the data array
2. getValueByDataKey already handles null | undefined for its first argument (as shown in the relevant code snippet: if (isNullish(obj) || isNullish(dataKey)) { return defaultValue; })

src/state/cartesianAxisSlice.ts (1)

33-38: No action needed. The type change is correct.

BaseCartesianAxis.scale should not include undefined because this type represents user-provided Redux configuration that always requires a scale value. The undefined handling is properly isolated to computed types: RechartsScale | undefined values are produced by selectors, and functions like rechartsScaleFactory explicitly handle undefined cases through overloads. There is no evidence of BaseCartesianAxis.scale being set to undefined anywhere in the codebase, and selectors that use this type deliberately narrow the scale property to non-undefined RechartsScale through the BaseAxisWithScale type derivation.

src/state/optionsSlice.ts (1)

30-41: LGTM — Good defensive typing for strict mode compliance.

The refactoring from a generic function to a typed constant with unknown input properly aligns with the TooltipPayloadSearcher type signature. The Array.isArray(data) guard and isNan check provide appropriate runtime safety.

src/util/scale/RechartsScale.ts (1)

147-170: LGTM — Well-structured overloads for type narrowing.

The overloads provide proper type inference for callers, ensuring that passing undefined explicitly returns undefined, while passing a concrete scale type returns a concrete RechartsScale. This is a good pattern for strict TypeScript compliance.

src/chart/Sankey.tsx (1)

508-528: LGTM — Proper defensive guards for unknown data.

The runtime guards for computedData correctly check for null before the typeof check (since typeof null === 'object' in JavaScript). The signature change to unknown aligns with the stricter TooltipPayloadSearcher type.

src/cartesian/Funnel.tsx (2)

581-585: LGTM — Safe numeric extraction with fallback.

Good defensive pattern: mapping values through getValueByDataKey and ensuring numeric output with a fallback to 0 for non-numeric values.

---

656-656: LGTM — Safe object spread with type guard.

The guard entry != null && typeof entry === 'object' correctly prevents spreading primitives or null values, which would cause runtime errors.

src/chart/Treemap.tsx (6)

72-72: LGTM — Strict index signature.

Changing from any to unknown enforces proper type checking when accessing arbitrary properties on TreemapNode, aligning with strict TypeScript guidelines.

---

75-88: LGTM — Well-implemented type guard.

The isTreemapNode function properly validates both the presence and types of required properties. The pattern of checking 'x' in value before casting is safe and idiomatic.

---

90-95: LGTM — Generalized payload searcher.

The signature change to unknown input/output aligns with TooltipPayloadSearcher and requires callers to validate the result (e.g., via isTreemapNode).

---

146-151: LGTM — Safe value extraction with fallback.

Using child.value directly (line 146) is cleaner than index access, and the leaf value extraction (lines 149-151) properly handles non-numeric values with a fallback to 0.

---

876-877: LGTM — Defensive name extraction.

Good pattern: extracting the raw value and validating it's a string before use, with a sensible fallback to 'root'.

---

923-923: LGTM — Proper use of type guard.

Using isTreemapNode(activeNode) before accessing properties ensures type safety after the treemapPayloadSearcher returns unknown.

src/shape/Curve.tsx (3)

23-24: LGTM!

Good aliasing choice to avoid confusion with recharts' own Area and Line components while maintaining clear D3-prefixed naming.

---

91-105: LGTM!

The explicit return type annotation and the null guard for the factory lookup improve type safety. The fallback logic correctly defers to the generic lookup at line 104 if the specialized monotone/bump factory isn't found.

---

217-245: LGTM!

The @ts-expect-error directive is well-documented with a thorough explanation of why d3's type definitions don't support this pattern. The approach is honest about the type limitation while maintaining runtime correctness—defined() filters nullable points before getX/getY are called.

Reviewing files that changed from the base of the PR and between 7ea742c and d5e4eba.

• src/chart/Treemap.tsx
• src/component/LabelList.tsx
• src/index.ts
• src/shape/Curve.tsx
• storybook/stories/API/chart/RadialBarChart.stories.tsx
• storybook/stories/API/chart/Treemap.stories.tsx
• storybook/stories/Examples/cartesian/Area/AreaWithCustomLabel.stories.tsx
• test/chart/LineChart.spec.tsx
• test/helper/expectStackGroups.ts
• tsconfig.json
• www/src/components/GuideView/ZIndex/PrahaMetro.tsx
• www/src/docs/exampleComponents/TreeMap/CustomContentTreemap.tsx

• GitHub Check: Build, Test, Pack
• GitHub Check: Analyze (javascript-typescript)

test/helper/expectStackGroups.ts (4)

5-10: LGTM! Excellent use of unknown for optional properties.

The SyncExpectationResult interface properly standardizes the matcher return type and correctly uses unknown for the optional actual and expected properties, aligning with the coding guideline to prefer unknown over any.

---

65-83: LGTM! Improved error handling and type safety.

The explicit SyncExpectationResult return type and the error guard on line 80 improve both type safety and runtime robustness. The previous direct access to e.message could have failed at runtime if the caught value wasn't an Error instance.

---

85-103: LGTM! Consistent type safety improvements.

The matcher follows the same robust pattern as rechartsStackedDataMatcher, with explicit return typing and safe error message extraction on line 100.

---

105-123: LGTM! Completes the consistent refactor across all matchers.

All three matchers now use the same standardized, type-safe pattern. The changes throughout this file successfully avoid any types and provide explicit type annotations, aligning perfectly with the strict TypeScript configuration goals of this PR.

src/chart/Treemap.tsx (5)

71-73: LGTM! Index signature improvement aligns with TypeScript best practices.

The change from any to unknown for the index signature follows the project's coding guidelines. The addition of the root field enables proper parent navigation in the treemap hierarchy.

Based on learnings, this aligns with the guideline to prefer unknown over any.

---

91-96: Verify breaking change to public API is intentional.

The signature change from TooltipPayloadSearcher<TreemapNode, TreemapNode> to generic TooltipPayloadSearcher (accepting/returning unknown) is a breaking change for consumers who rely on the typed signature. This reduces type safety for callers.

If this change is necessary for strict TypeScript compliance, ensure it's documented in the PR description or migration notes.

---

146-153: LGTM! Improved type safety by using typed field.

The change from child[NODE_VALUE_KEY] to child.value and the safe numeric value extraction with type checking and fallbacks improve type safety and align with strict TypeScript mode.

---

877-878: LGTM! Safe name extraction with proper type narrowing.

The defensive pattern using get() with a fallback and subsequent type narrowing ensures name is always a string, preventing runtime errors from unexpected data types.

---

913-926: LGTM! Proper runtime validation prevents potential errors.

The type guard usage ensures activeNode is valid before accessing its properties, preventing runtime errors in touch event handling.

www/src/docs/exampleComponents/TreeMap/CustomContentTreemap.tsx (1)

152-152: LGTM! Safe access pattern prevents potential runtime errors.

The optional chaining with nullish coalescing operator properly handles the case where root.children is null, which is allowed by the TreemapNode interface definition.

src/index.ts (1)

29-29: LGTM! Public API export follows established patterns.

The addition of LabelListEntry to the public API exports enables consumers to properly type their label list entries, improving TypeScript support.

storybook/stories/API/chart/Treemap.stories.tsx (2)

4-4: LGTM! Proper import from public API.

The import of TreemapNode from the public API entry point aligns with the coding guideline that all imports from recharts should use the public API entry point.

Based on learnings, this follows the project's import conventions.

---

152-163: LGTM! Improved type safety and defensive coding.

The explicit TreemapNode type annotation on the content function parameter and the safe access pattern for root.children?.length ?? 1 improve type safety and prevent potential runtime errors.

Based on learnings, updating Storybook stories when APIs change ensures they work as expected.

test/chart/LineChart.spec.tsx (1)

9-9: LGTM! Using public type improves test type safety.

Importing and using LabelProps from the public API instead of an inline type annotation improves maintainability and ensures tests stay in sync with the component API.

Also applies to: 495-502

storybook/stories/API/chart/RadialBarChart.stories.tsx (2)

6-15: LGTM! Explicit type imports improve type safety.

The addition of DefaultLegendContentProps and LegendPayload types provides proper typing for the Legend payload handling, aligning with the project's strict TypeScript configuration.

---

47-47: LGTM! Explicit type annotations align with strict TypeScript configuration.

The explicit typing of useState, the Legend content function parameter, and the payload mapping improves type safety and follows the coding guidelines for explicit function parameter types.

Also applies to: 63-63, 65-65

tsconfig.json (1)

2-2: LGTM! Centralizing configuration via base tsconfig.

Extending from tsconfig.base.json is a good practice that centralizes strict compiler options and ensures consistency across the project's TypeScript configurations.

storybook/stories/Examples/cartesian/Area/AreaWithCustomLabel.stories.tsx (1)

2-2: LGTM! Using public LabelProps type.

Replacing the inline type annotation with the public LabelProps type improves consistency and maintainability. The destructuring of { index, x, y } works correctly with the LabelProps interface.

Also applies to: 12-12

src/component/LabelList.tsx (4)

15-27: LGTM! Exporting LabelListEntry improves type safety.

Making LabelListEntry a public interface enables consumers to properly type their code when working with label list entries, as demonstrated in the storybook files and www components.

---

25-25: LGTM! Replacing any with unknown follows coding guidelines.

The change from Record<string, any> to Record<string, unknown> for the payload property aligns with the project's coding guidelines that prefer unknown over any. The payload is intentionally generic because its shape depends on user-provided data.

Based on learnings, prefer unknown over any and refine the type in TypeScript.

Also applies to: 80-80

---

37-37: LGTM! Type hierarchy updates maintain consistency.

The updates to CartesianLabelListEntry, PolarLabelListEntry, and defaultAccessor to use the new LabelListEntry base interface maintain type consistency across the component while preserving the existing public API surface.

Also applies to: 46-50, 148-148

---

184-184: LGTM! Simplified data access.

The updated getValueByDataKey call passing entry.payload directly (instead of entry && entry.payload) is cleaner, as the entry parameter is guaranteed to be defined at this point in the map iteration.

src/shape/Curve.tsx (3)

23-24: LGTM: Clear and specific import names.

The renamed imports (D3AreaCurve, D3LineCurve) improve clarity by making the D3 origin explicit and avoiding potential naming conflicts with other Area/Line types in the codebase.

---

91-104: LGTM: Improved type safety and defensive coding.

The explicit return type on line 91 clarifies the function contract, and the null guard on lines 100-102 correctly handles the case where the dynamically constructed key might not exist in CURVE_FACTORIES, allowing the fallback on line 104 to handle it appropriately.

---

217-217: The ts-expect-error directives are an appropriate workaround for a known d3-shape type limitation.

The code correctly documents why type suppression is necessary: d3's single-generic parameter prevents expressing how .defined() transforms the function to accept nullable inputs while filtering them internally. Since:

• @types/d3-shape (3.1.6) has not resolved this limitation
• The coding guidelines forbid as assertions (the alternative)
• The runtime behavior is correct (.defined() filters nulls before passing to getX/getY)

The ts-expect-error approach with detailed comments is the appropriate solution. No changes needed.