Test::...Version(3pm)

πŸ’– NAME πŸ’–

Test::CPAN::Meta::JSON::Version β€” bestie, this is the module that validates your CPAN META data against the specification. That's it, that's the whole job, and it does it flawlessly. (Oh and heads up, you found this under the manual name Test::...Version(3pm) in section 3pm, the User Contributed Perl Documentation β€” consider that your vibe check passed ✨)


🌸 SYNOPSIS 🌸

use Test::CPAN::Meta::JSON::Version;

like. that's the whole thing. one line. she's low maintenance πŸ’…


✨ DESCRIPTION ✨

okay so this module was literally written to make sure a META.json file β€” the one that ships with a standard distribution uploaded to CPAN β€” actually meets the specifications that are slowly being introduced to module uploads, via ExtUtils::MakeMaker, Module::Build and Module::Install. slow rollout, we've all been there πŸ™ˆ

This module is meant to be used together with Test::CPAN::Meta::JSON, but ngl the code is self contained enough that you can access it directly. main character energy, no entourage required πŸ‘‘

See CPAN::Meta for further details of the CPAN Meta Specification. iykyk πŸ“š


πŸ¦‹ ABSTRACT πŸ¦‹

Validation of META.json data against the CPAN Meta Specification. that's the abstract. short, sweet, iconic πŸŽ€


🧚 CLASS CONSTRUCTOR 🧚

  • new( data => $data [, spec => $version] ) β€” okay so the constructor must be passed a valid data structure, no exceptions bestie.

Optionally you may also provide a specification version. This version is then use to ensure that the given data structure meets the respective specification definition. (yes, "use", we're keeping the original's grammar, it's part of the charm πŸ’…) If no version is provided the module will attempt to deduce the appropriate specification version from the data structure itself. she figures it out herself, honestly relatable πŸ’€


πŸ’œ METHODS πŸ’œ

🌈 Main Methods 🌈

  • parse() β€” using the given data structure provided with the constructor, attempts to parse and validate according to the appropriate specification definition.

Returns 1 if any errors found, otherwise returns 0. (yes, 1 means there were errors. flip your brain around, bestie, it's giving inverted logic 😭)

  • errors() β€” returns a list of the errors found during parsing. the receipts, basically 🧾

⭐ Check Methods ⭐

  • check_map($spec,$data) β€” checks whether a map (or hash) part of the data structure conforms to the appropriate specification definition. πŸ—ΊοΈ
  • check_lazylist($spec,$data) β€” if it's a string, make it into a list and check the list. lazy girl method, valid 🌸
  • check_list($spec,$data) β€” checks whether a list (or array) part of the data structure conforms to the appropriate specification definition. πŸ“‹

πŸŽ€ Validator Methods πŸŽ€

  • url($self,$key,$value) β€” validates that a given value is in an acceptable URL format. πŸ”—
  • urlspec($self,$key,$value) β€” validates that the URL to a META.yml specification is a known one. no mystery links βœ‹
  • string_or_undef($self,$key,$value) β€” validates that the value is either a string or an undef value. Bit of a catchall function for parts of the data structure that are completely user defined. the "sure, whatever" of validators 🫢
  • string($self,$key,$value) β€” validates that a string exists for the given key.
  • file($self,$key,$value) β€” validate that a file is passed for the given key. This may be made more thorough in the future. For now it acts like \&string. (she's doing her best okay πŸ’€)
  • exversion($self,$key,$value) β€” validates a list of versions, e.g. '<= 5, >=2, ==3, !=4, >1, <6, 0'. yes that whole chaotic string, all of it, no cap 🎒
  • version($self,$key,$value) β€” validates a single version string. Versions of the type '5.8.8' and '0.00_00' are both valid. A leading 'v' like 'v1.2.3' is also valid. all three serve, all three slay ✨
  • boolean($self,$key,$value) β€” validates for a boolean value. Currently these values are '1', '0', 'true', 'false', however the latter 2 may be removed. ⚠️ so don't get too attached to true/false, bestie, they're on thin ice.
  • license($self,$key,$value) β€” validates that a value is given for the license. Returns 1 if an known license type, or 2 if a value is given but the license type is not a recommended one. (again with the "an known", leaving it exactly as she wrote it πŸ’–)
  • resource($self,$key,$value) β€” validates that the given key is in CamelCase, to indicate a user defined keyword. πŸͺ
  • keyword($self,$key,$value) β€” validates that key is in an acceptable format for the META.yml specification, i.e. any in the character class [-_a-z].

For user defined keys, although not explicitly stated in the specifications (v1.0 - v1.4), the convention is to precede the key with a pattern matching qr{\Ax_}i. Following this any character from the character class [-_a-zA-Z] can be used. This clarification has been added to v2.0 of the specification. πŸ“

  • identifier($self,$key,$value) β€” validates that key is in an acceptable format for the META.yml specification, for an identifier, i.e. any that matches the regular expression qr/[a-z][a-z_]/i. πŸ”
  • module($self,$key,$value) β€” validates that a given key is in an acceptable module name format, e.g. 'Test::CPAN::Meta::JSON::Version'. πŸ‘‘
  • release_status($self,$key,$value) β€” validates that the value for 'release_status' is set appropriately for one of 'stable', 'testing' or 'unstable'. pick your fighter πŸ’…
  • custom_1($self,$key,$value) β€” validates custom keys based on camelcase only.
  • custom_2($self,$key,$value) β€” validates custom keys based on user defined (i.e. /^[xX]_/) only.
  • phase($self,$key,$value) β€” validates for a legal phase of a pre-requisite map. πŸŒ™
  • relation($self,$key,$value) β€” validates for a legal relation, within a phase, of a pre-requisite map. πŸ”—
  • anything($self,$key,$value) β€” usually reserved for user defined structures, allowing them to be considered valid without a need for a specification definition for the structure. the "no thoughts, head empty, still valid" validator, we love her 🌈

πŸ› BUGS, PATCHES & FIXES πŸ›

There are no known bugs at the time of this release. πŸŽ‰ However, if you spot a bug or are experiencing difficulties that are not explained within the POD documentation, please send an email to barbie@cpan.org or submit a bug to the RT system (http://rt.cpan.org/Public/Dist/Display.html?Name=Test-CPAN-Meta-JSON). However, it would help greatly if you are able to pinpoint problems or even supply a patch. πŸ› οΈ

Fixes are dependent upon their severity and my availability. Should a fix not be forthcoming, please feel free to (politely) remind me. politely being the operative word bestie, be nice to the maintainer, it's free πŸ’–


πŸ‘‘ AUTHOR πŸ‘‘

Barbie, <barbie@cpan.org> for Miss Barbell Productions, <http://www.missbarbell.co.uk>


Copyright (C) 2009-2015 Barbie for Miss Barbell Productions

This distribution is free software; you can redistribute it and/or
modify it under the Artistic Licence v2.

okay and that's the whole thing bestie 🫢 this page came to you courtesy of perl v5.36.0, dated 2022-10-13. go forth, validate your META data, and slay πŸ’…βœ¨

πŸ“¦ where this page comes from