prefer_string_parse_extensions

v1.0.0WarningFixConfigurablefpdart

This rule flags Option.fromNullable(...) wrapping an int.tryParse, double.tryParse, num.tryParse or bool.tryParse call.

Why use this rule

fpdart defines toIntOption as literally Option.fromNullable(int.tryParse(this)), along with toDoubleOption, toNumOption, toBoolOption and the ...Either variants that carry a failure. Writing the composition out reimplements something the package ships.

It also separates the parse from its null handling by the width of the line. Inside a pipeline that is where the mismatch hides — Option.fromNullable(int.tryParse(a)) in a step that meant to parse b reads as perfectly correct.

See also: fpdart: string extensions

Don’t

final parsed = Option.fromNullable(int.tryParse(input));

Do

final parsed = input.toIntOption;

When the failure has to reach the caller, the Either variant takes it:

Either<Failure, int> parseRound(String input) =>
    input.toIntEither(() => const InvalidRoundNumberFailure());

Quick fix

A quick fix rewrites the whole expression to value.toIntOption (and the other three), adding the fpdart import when it is missing. It can be applied across a whole file at once.

Only the four built-in receivers are rewritten. A type added through additional_parsers still gets the warning but no fix — the extension to call is that project’s own, and its name cannot be derived reliably enough to edit code with.

Known limitations

A tryParse call with a second argument (radix:) is left alone — it does something no extension covers.

An unrelated tryParse (a user-defined Version.tryParse, say) is not reported unless it is named in additional_parsers, since no matching extension exists by default.

many_lints:
  rules:
    prefer_string_parse_extensions:
      additional_parsers:
        - Version

rules:
  prefer_string_parse_extensions:
    additional_parsers:
      - Version

Option	Type	Default	Description
`additional_parsers`	list of strings	`[]`	Extra `Type.tryParse` receivers to recognise, for projects with their own `toXOption` extension. The suggested getter is derived as `to<Type>Option`

Configuration

This rule is in the opinionated preset. With a lower preset, enable it by name with prefer_string_parse_extensions: true.

To turn it off:

rules:
  prefer_string_parse_extensions: false

To keep the rule on but skip certain paths, use per-rule exclude.

avoid_ad_hoc_left_type — A pipeline only composes when every step shares one error type.
avoid_bare_await_in_do — Awaiting a raw Future inside a Do block escapes the block’s tracking.
avoid_dollar_outside_do_frame — Calling a Do block’s extraction function from a nested callback unwinds through code that cannot handle it.
avoid_either_of_future — A Future nested in Either or Option escapes the error channel.