SYNOPSIS

    In dist.ini:

     [Rinci::Validate]

    In your module:

     $SPEC{foo} = {
         args => {
             arg1 => { schema => ['int*', default=>3] },
             arg2 => { },
         },
     };
     sub foo {
         my %args = @_;
    
         my $arg1 = $args{arg1}; # VALIDATE_ARG
         ...
     }

    output will be something like:

     $SPEC{foo} = {
         args => {
             arg1 => { schema => ['int*', default=>3] },
             arg2 => { },
         },
     };
     sub foo {
         my %args = @_;
    
         my $arg1 = $args{arg1}; require Scalar::Util::Numeric; my $arg_err; (($arg1 //= 3), 1) && ((defined($arg1)) ? 1 : (($err_arg1 = 'TMPERRMSG: required data not specified'),0)) && ((Scalar::Util::Numeric::isint($arg1)) ? 1 : (($err_arg1 = 'TMPERRMSG: type check failed'),0)); return [400, "Invalid value for arg1: $err_arg1"] if $arg1; # VALIDATE_ARG
         ...
     }

    You can also validate all arguments:

     sub foo {
         my %args = @_; # VALIDATE_ARGS
    
         ...
     }

DESCRIPTION

    This plugin inserts argument validation code into your module source
    code, at location marked with # VALIDATE_ARG or # VALIDATE_ARGS.
    Validation code is compiled using Data::Sah from Sah schemas specified
    in args property in Rinci function metadata in the module.

    This plugin detects the more recently developed plugin
    Dist::Zilla::Plugin::Rinci::Wrap and will skip running if the latter is
    loaded.

 USAGE

    To validate a single argument, in your module:

     sub foo {
         my %args = @_;
         my $arg1 = $args{arg1}; # VALIDATE_ARG

    The significant part that is interpreted by this module is my $arg1.
    Argument name is taken from the lexical variable's name (in this case,
    arg1). Argument must be defined in the args property of the function
    metadata. If argument name is different from lexical variable name,
    then you need to say:

     my $f = $args->{frobnicate}; # VALIDATE_ARG frobnicate

    To validate all arguments of the subroutine, you can say:

     sub foo {
         my %args = @_; # VALIDATE_ARGS

    There should only be one VALIDATE_ARGS per subroutine.

    If you use this plugin, and you plan to wrap your functions too using
    Perinci::Sub::Wrapper (or through Perinci::Access, Perinci::CmdLine,
    etc), you might also want to put
    x.perinci.sub.wrapper.disable_validate_args => 1 attribute into your
    function metadata, to instruct Perinci::Sub::Wrapper to skip generating
    argument validation code when your function is wrapped, as argument
    validation is already done by the generated code.

    If there is an unvalidated argument, this plugin will emit a warning
    notice. To skip validating an argument (silence the warning), you can
    use:

     sub foo {
         my %args = @_;
         my $arg1 = $args{arg1}; # NO_VALIDATE_ARG

    or:

     sub foo {
         # NO_VALIDATE_ARGS

FAQ

 Rationale for this plugin?

    This plugin is an alternative to Perinci::Sub::Wrapper, at least when
    it comes to validating arguments. Perinci::Sub::Wrapper can also
    generate argument validation code (among other things), but it is done
    during runtime and can add to startup overhead (compiling complex
    schemas for several subroutines can take up to 100ms or more, on my
    laptop). Using this plugin, argument validation code is generated
    during building of your distribution.

    Using this plugin also makes sure that argument is validated whether
    your subroutine is wrapped or not. Using this plugin also avoids
    wrapping and adding nest level, if that is not to your liking.

    Instead of using this plugin, you can use wrapping either by using
    Perinci::Exporter or by calling Perinci::Sub::Wrapper's wrap_sub
    directly.

 But why use Rinci metadata or Sah schema?

    In short, adding Rinci metadata to your subroutines allows various
    tools to do useful stuffs, relieving you from doing those stuffs
    manually. Using Sah schema allows you to write validation code
    succintly, and gives you the ability to automatically generate
    Perl/JavaScript/error messages from the schema.

    See their respective documentation for more details.

 But the generated code looks ugly!

    Admittedly, yes. Validation source code is formatted as a single long
    line to avoid modifying line numbers, which is desirable when debugging
    your modules. An option to not compress everything as a single line
    might be added in the future.

SEE ALSO

    Dist::Zilla::Plugin::Rinci::Wrap

    Data::Sah::Manual::ParamsValidating