The majority of the size of the distribution is the test suite. With nearly 1200 CPAN modules depending on Type::Tiny directly or indirectly, having a comprehensive test suite seems a good idea. Documentation and examples make up most of the remaining size.

In terms of dependancies, the module Type::Tiny itself has no non-core dependancies (apart from a few modules that are bundled with it).

$ perl -Ilib -MType::Tiny -E'say for sort keys %INC'
Eval/TypeTiny.pm
Exporter.pm
List/Util.pm
Scalar/Util.pm
Type/Tiny.pm
Type/Tiny/XS.pm
Types/TypeTiny.pm
XSLoader.pm
feature.pm
overload.pm
overloading.pm
strict.pm
warnings.pm
warnings/register.pm
[download]

As you can see, they're all in core, except:

• Eval::TypeTiny — not in core, but bundled with Type::Tiny
• Type::Tiny::XS — loaded via eval { require Type::Tiny::XS } so it's an optional dependancy
• Types::TypeTiny — not in core, but bundled with Type::Tiny

The module I recommended, Types::Common::Numeric does have one additional non-core dependancy: Exporter::Tiny.

Exporter::Tiny was originally called Exporter::TypeTiny and bundled as part of the distribution too. However, I was convinced by chocolateboy that it had merit as a standalone module, so I split it out as a separate CPAN distribution. Seems he was right as it now has nearly 4000 downstream dependants. I don't think the fact that some of the modules bundled with Type::Tiny (but not Type::Tiny itself) require Exporter::Tiny makes it unworthy of the "tiny" name.

Yes, if it's just one range check in a script, requiring any module whatsoever seems like overkill. But realistically, problems like this don't come up in isolation. Most non-trivial programs will need to sanity-check data in loads of places — checking the data passed to object constructors, checking function and method arguments, etc. Type::Tiny and its bundled modules provide a framework for this which is more concise and usually more correct and faster than handwritten code.

As an example of correctness, spot the problem with this code:

use strict;
use warnings FATAL => qw(all);

sub set_age {
  my $self = shift;
  my ($age) = @_;

  croak "age cannot be negative" unless $age >= 0;

  $self->{age} = $age;
  return $self;
}
[download]

Okay, so the obvious thing is we're not checking $age is a number. But if we do $object->set_age("old") we'll get a warning about doing a numeric comparison on a string, so we're covered, right?

Wrong. $object->set_age([]) will be allowed. Numeric operations on references silently act on their reference address without triggering any warnings.

Rewriting it to this:

use feature "state";
use strict;
use warnings FATAL => qw(all);
use Type::Params qw(compile);
use Types::Standard qw(Object);
use Types::Common::Numeric qw(PositiveOrZeroInt);

sub set_age {
  state $check = compile(Object, PositiveOrZeroInt);
  my ($self, $age) = $check->(@_);
  $self->{age} = $age;
  return $self;
}
[download]

And as a bonus, it will test that $self is an object, and will check that @_==2.

None of the other answers to the OP's question even bothered checking $x was actually a number. IntRange will check that it's defined, it's a non-reference, and it's an integer before checking that it's in the right range.