Remember that a cron-job is run by a daemon that probably runs as nobody, and that it will run in as “pristine” an environment as possible.   Therefore, what I normally do is to run a stub shell-script which in turn invokes a stub Perl-program.   For example:

myjob.sh:

 #!/usr/bin/bash
/usr/bin/perl /path/to/somewhere/cronstub.pl
[download]

cronstub.pl:   (Note:   I’m just makin’ this stuff up on the fly ...)

#!/usr/bin/perl
use strict;
use warnings;
use lib qw(/path/to/where/everything/lives);
use main_module;
exec { 
  main_module();
  return 0;
}
if ($@) {
  print STDERR "Cron job failed: $@\n";
  return -1;
}
[download]

Notice:   (and many of these are just my personal idiosyncrasies ...)

1. Everything is explicit.   Path names to everything including Perl are spelled-out.
   • You’re absolutely right that, if anything changes, you’ll have to change the cron-job.   (Don’t forget to check-in the revised version back into the version-control system ...)
   • If you have many such jobs, make it easy on yourself and adopt a consistent side-wide standard modus operandi.)
2. The stub uses a use lib statement, not a dependency on $PERL5LIB, to specify where the application lives.   It then uses the application main module and invokes it.   At this point, the main-program should be running in whatever is its “proper” environment, cron or not.
3. The stub Perl program sets a meaningful return-code value.   It traps runtime errors, reports them if they occur, and sets a sentinel return-code value.