In an effort to reduce some of my boilerplate, I wrote
Import::Base, a module to collect and
import useful bundles of modules, removing the need for long lists of use ...
lines everywhere.

As I've grown as a Perl programmer, I've added more and more to my standard
preamble for all but the most trivial Perl scripts. use strict and use
warnings are absolute requirements. I want to use modern Perl's features like
say, state, and others, so I'll import a feature bundle with use feature
":5.10". If I'm working on things I don't plan to share the code on CPAN, I
can go all the way to use experimental qw( signatures postfix_deref ).

For class modules, I need to use Moo, use Types::Standard, and more. For
roles, I need to use Moo::Role instead of Moo. If the project uses Moose, I
need to use Moose's version of those things instead of Moo's version (or, in
the case of Type::Tiny, make sure to use a Moo/Moose agnostic pattern).

For tests, I have a lot more. use Test::More, use Test::Deep, and use
Test::Differences, are my go-to comparison set. My best practices also include
use File::Temp, which requires that I use File::Spec::Functions, and use
FindBin so I can locate the t/share directory for ancillary test files.

For command-line scripts, I have use Pod::Usage::Return, use Getopt::Long
qw( GetOptionsFromArray ), in addition to my standard boilerplate of strict,
warnings, and features.

And every project I write has imports that are used in just about every module:
YAML, JSON, Path::Tiny, and project-specific utility modules.

My standard solution was as simple and blunt as it could be: Copy and paste.
Besides being a stupidly-lazy solution, it left me with a problem: How could I
modify all my modules to use a new feature bundle? Should I brush up on my
sed(1) or write a Perl one-liner? What happens when I want to use a different
module with an equivalent API, like changing to use YAML::XS instead of
YAML::PP? How can I make a new module quickly available to all my classes, or
all my roles, or all my tests, or all my scripts?

All these questions boiled down to: If I copy/paste my boilerplate everywhere,
what happens when my boilerplate changes? This is why I hate boilerplate.

With Import::Into, we have a way to
remove a massive block of imports from our boilerplate. Using Import::Into, I
wrote a simple class to manage my imports, and allow me to quickly create
different bundles of imports to use in different situations:
Import::Base.

With Import::Base, you build a list of imports in a module. When someone
imports your module, they get all your imports. They can also subclass your
module to add or remove what your module imports.

A common base module should probably include strict, warnings, and a feature
set.

What makes Import::Base more useful than rolling your own with Import::Into is
the granular control you can get on the consuming side. On a case-by-case
basis, individual imports can be removed if they conflict with something in the
module (a name collision, for example). Then, the offending module can be used
directly.