feat: add fieldName property to validation error objects

[gsriram24]

Description

This PR adds a fieldNames property to validation error objects, enabling consumers to programmatically identify which field caused a validation error without parsing the issueMessage string.

Changes:

Core (src/types/base.js):

• required() — returns fieldNames: [name] for missing/invalid type errors
• recommended() — returns fieldNames: [name] for missing/invalid type warnings
• or() — returns fieldNames (all fields) for compound conditions

Custom validators:

• BreadcrumbList.js — fieldNames for item count and URL validation errors
• DefinedRegion.js — fieldNames for addressRegion/postalCode conflict
• MerchantReturnPolicy.js — fieldNames for country/link validation
• Product.js — fieldNames for rating/review/offers and notes count errors
• ProductMerchant.js — fieldNames for GTIN validation
• Rating.js — fieldNames for out-of-range rating errors
• schemaOrg.js — fieldNames for unsupported property errors

Tests:

• Added base.test.js with 10 new tests covering fieldNames behavior

Related Issue

Fixes #55

Motivation and Context

Currently, the field name is embedded in the issueMessage string:

{ issueMessage: 'Required attribute "price" is missing', ... }

Consumers must use regex to extract the field name, which is fragile and breaks if message wording changes. This PR adds a dedicated fieldName property for direct programmatic access, enabling use cases like:

• Highlighting specific form fields in structured data editors
• Building field-level error mappings without string parsing
• Future-proofing against message wording or i18n changes

How Has This Been Tested?

• All 211 existing tests pass
• Added 10 new tests in base.test.js covering:
  • required() returning fieldNames for missing attributes
  • required() returning fieldNames for invalid type
  • recommended() returning fieldNames for missing/invalid attributes
  • or() returning fieldNames for compound conditions
  • Nested path fieldNames (e.g., offers.price)

npm run unit-test
# 211 passing

Screenshots (if appropriate):

N/A

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

• I have signed the Adobe Open Source CLA.
• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes.
• All new and existing tests passed.

---

[herzog31]

Thanks for your contribution 💯

Could you please also ensure that the changes related to fieldName made to

• BreadcrumbList.js
• DefinedRegion.js
• MerchantReturnPolicy.js
• Product.js
• ProductMerchant.js
• Rating.js
• schemaOrg.js
  are also covered by unit tests? Extending existing tests is fine.

[gsriram24]

@herzog31, updated the test files to assert for fieldNames too!

[herzog31]

Thanks a lot @gsriram24 for the contribution.