Dist-Zilla
view release on metacpan or search on metacpan
6.005 2016-05-23 08:08:15-04:00 America/New_York
- NextRelease now dies if there's no changelog file found
(thanks, Karen Etheridge)
- Module::Runtime replaces Class::Load (thanks Olivier Mengué)
6.004 2016-05-14 09:14:19-04:00 America/New_York (TRIAL RELEASE)
- stop listing Path::Class as a prereq (thanks, Karen Etheridge)
- update docs on path types (thanks, Graham Ollis)
6.003 2016-04-24 19:23:46+01:00 Europe/London (TRIAL RELEASE)
- leading BOM (FEFF) is stripped on UTF-8 content
- PPI now handles characters, not bytes, fixing non-ASCII
non-comments in your source
6.002 2016-04-23 17:50:26+01:00 Europe/London (TRIAL RELEASE)
- tweaks to Dist::Zilla::Path to keep plugins from v5 era working
6.001 2016-04-23 13:21:56+01:00 Europe/London
[THIS RELEASE MIGHT BREAK YOUR BUILD]
- Using a Dist::Zilla::Path like a Path::Class object now issues a
deprecation warning ("this will be removed") once per call site.
lib/Dist/Zilla/Role/File.pm view on Meta::CPAN
my $enc = $self->encoding;
if ( $self->is_bytes ) {
$self->_throw(decode => "Can't decode text from 'bytes' encoding");
}
else {
require Encode;
my $text =
try { Encode::decode($enc, $bytes, Encode::FB_CROAK()) }
catch { $self->_throw("decode $enc" => $_) };
# Okay, look, buddy⦠If you're using a BOM on UTF-8, that's fine. You can
# use it. You're just not going to get it back. If we don't do this, the
# sequence of events will be:
# * read file from UTF-8-BOM file on disk
# * end up with FEFF as first character of file
# * pass file content to PPI
# * PPI blows up
#
# I'm not going to try to account for the BOM and add it back. It's awful!
#
# Meanwhile, if you're using UTF-16, you can get the BOM handled by picking
# the right encoding type, I think. -- rjbs, 2016-04-24
$enc =~ /^utf-?8$/i && $text =~ s/\A\x{FEFF}//;
return $text;
}
}
sub _throw {
my ($self, $op, $msg) = @_;
my ($name, $added_by) = map {; $self->$_ } qw/name added_by/;
( run in 0.409 second using v1.01-cache-2.11-cpan-e9daa2b36ef )