feat(tsconfig): parse strict and strictNullChecks compiler options

[kylecannon]

Summary

CompilerOptions models only the options the resolver/transformer pipeline consumes (paths, baseUrl, jsx*, experimentalDecorators, emitDecoratorMetadata, useDefineForClassFields, verbatimModuleSyntax, target, module, and so on). It has no field for strict or strictNullChecks, so even when a user sets them in tsconfig.json the value is dropped at parse time, leaving a downstream consumer nothing to read.

This blocks consumers (for example rolldown's merge_transform_options_with_tsconfig) from inferring strictNullChecks from a tsconfig and forwarding it to the transformer, where it controls whether null/undefined are elided from union design:type annotations under legacy emitDecoratorMetadata. Today that can only be set via the explicit transform.decorator.strictNullChecks option.

This PR adds the two fields, inherits them through extends, and exposes a resolver that applies TypeScript's precedence rule.

TypeScript semantics

tsc resolves the flag as strictNullChecks ?? strict (see getStrictOptionValue: options[flag] === undefined ? !!options.strict : options[flag]):

• an explicit strictNullChecks always wins over the value implied by strict, in either direction;
• when strictNullChecks is absent it falls back to strict;
• strict: false on its own therefore yields false.

effective_strict_null_checks() implements exactly this with self.strict_null_checks.or(self.strict). It returns None only when neither is set, deliberately leaving the final default to the consumer rather than baking one into the resolver (the common transformer default is true).

The two fields are merged independently in extend_tsconfig (mirroring emitDecoratorMetadata), so the precedence rule stays correct across an extends chain: the nearest explicit strictNullChecks still wins over a strict set in any ancestor, consistent with the later-wins merge from #1156.

Changes

• src/tsconfig.rs
  • CompilerOptions: add strict: Option<bool> and strict_null_checks: Option<bool> (serde camelCase mapping, no per-field rename).
  • extend_tsconfig: inherit both fields independently from the extended config.
  • new effective_strict_null_checks() accessor (#[must_use]).
• src/tests/tsconfig_extends.rs
  • test_effective_strict_null_checks_resolution: full truth table (strict:true alone, explicit strictNullChecks:false override, strict:false alone, neither).
  • test_extend_tsconfig_strict_null_checks: a child's explicit strictNullChecks:false survives inheriting a parent's strict:true; a child with neither inherits the parent's strict.

Purely additive. All existing tests pass (cargo test and cargo test --all-features, clippy -D warnings, cargo doc -D warnings, fmt, typos, and the NAPI JS suite all green locally).

Follow-up (separate, downstream)

This is the enabling resolver-side change. Inferring the value end to end is a downstream PR in rolldown: forward compiler_options.effective_strict_null_checks() in merge_transform_options_with_tsconfig into DecoratorOptions.strict_null_checks (mapping None to keep the transformer default), and add the field to its inline BindingTsconfigCompilerOptions for the non-disk config path.

🤖 Generated with Claude Code

[codspeed]

Merging this PR will improve performance by 5.77%

⚠️ Different runtime environments detected

Some benchmarks with significant performance changes were compared across different runtime environments,
which may affect the accuracy of the results.

Open the report in CodSpeed to investigate

⚡ 1 improved benchmark
✅ 12 untouched benchmarks
⏩ 5 skipped benchmarks¹

Performance Changes

	Benchmark	BASE	HEAD	Efficiency
⚡	resolver_real[multi-thread]	411 µs	388.6 µs	+5.77%

Tip

Curious why this is faster? Comment @codspeedbot explain why this is faster on this PR, or directly use the CodSpeed MCP with your agent.

---

_{Comparing kylecannon:tsconfig-strict-null-checks (d4e53e3) with main (827b45a)}

Footnotes

1. 5 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩