feat(helpers): pass propName to validate by Kikobeats · Pull Request #868 · microlinkhq/metascraper

Kikobeats · 2026-08-09T06:30:46Z

Why

findRule already receives the property it is resolving and uses it only for a debug label. validate never sees it, so a consumer cannot scope itself by property — and the same bytes want opposite answers depending on which one it is: a script-bearing HTML document is a hostile logo candidate and the expected url result.

Without propName, callers reach for proxies, and both of the obvious ones are wrong:

Comparing the value to the page URL, standing in for "this is the url property". Mismatches both ways: a logo that happens to equal the page URL goes ungated, and a url rule returning a canonicalised variant (trailing slash) gets rejected.
Exempting a content type, standing in for "this might be a page". It then applies to every property and every caller, which turns a page-shaped allowance into a global hole.

We hit exactly this downstream: an executable-markup gate for logo could not be scoped, so a text/html exemption had to live in the byte-level predicate, where any origin serving that content type passes.

What

propName rides on the options object:

validate: (value, { propName, url }) => propName !== 'logo' || value !== url

The documented (value, options, debug) signature is unchanged, so existing validates keep working — this is additive.

The options object is built once per property inside findRule, not per candidate, and only when a validate is present, so a scrape without one allocates nothing new.

Test plan

validate receives the property name it is judging — asserts both properties are seen and that rejecting only logo nulls it while title survives. Verified to fail without the change.
Existing validate suite unchanged: 8 passing.
tsd passes with a new case exercising propName.
metascraper unit 29 passing; metascraper-helpers 80 passing under TZ=UTC.

Note: .date fails on a non-UTC machine on master as well (Jun 20 with no year) — pre-existing and unrelated.

Note

Low Risk
Additive API and a small options copy only when validate is set; no change to default validation behavior.

Overview
Scrape-level validate callbacks now receive propName on the options object (alongside existing fields like url), so consumers can accept or reject the same candidate value differently per metadata field—for example blocking a text/html URL for logo while allowing it for url.

In findRule, when a validate is configured, options are shallow-copied once per property with propName set before isValidValue runs; scrapes without validate avoid the extra object. Type definitions and tsd cover the new field; a unit test confirms each property is validated independently.

^{Reviewed by Cursor Bugbot for commit b488d44. Bugbot is set up for automated code reviews on this repo. Configure here.}

Summary by CodeRabbit

Bug Fixes
- Improved metadata validation so candidates can be evaluated according to the property they populate.
- Prevented unsuitable values from being accepted for specific fields while preserving valid results for others.
- Added property-specific validation context to improve consistency when resolving multiple metadata fields.
Documentation
- Updated validation type information to clarify that validators receive the property name and page URL as context.

`findRule` already receives the property it is resolving and used it only for a debug label. A validate could not see it, so a consumer gating on value shape had no way to scope itself — and the same bytes want opposite answers depending on the property: a script-bearing HTML document is a hostile `logo` candidate and the expected `url` result. Without it, callers substitute proxies. Comparing the value against the page URL stands in for "this is the url property", which mismatches both ways: a `logo` that happens to equal the page URL goes ungated, and a `url` rule returning a canonicalised variant gets rejected. Exempting a content type stands in for "this might be a page", which then applies to every property. `propName` rides on the options object, so the documented `(value, options, debug)` signature is unchanged and existing validates keep working. The object is built once per property rather than per candidate, and only when a validate is present. Co-Authored-By: Claude Opus 5 <[email protected]> Claude-Session: https://claude.ai/code/session_01YKVuh1R8HtB7SX7eKa7UsJ

coderabbitai · 2026-08-09T06:31:08Z

📝 Walkthrough

Walkthrough

Validation callbacks now receive the current metadata property name. The TypeScript contract documents the required context, and type-level and unit tests verify property-specific validation.

Changes

Property-aware validation

Layer / File(s)	Summary
Pass property context to validation `packages/metascraper-helpers/src/index.js`	`findRule` adds `propName` to validation arguments when validation is enabled and passes those arguments to candidate validation.
Update validation contracts and coverage `packages/metascraper/src/index.d.ts`, `packages/metascraper/test/types/index.test-d.ts`, `packages/metascraper/test/unit/validate.js`	The `Validate` type requires `options.propName`. Type-level and unit tests verify property-specific validation for `logo` and `title`.

Estimated code review effort: 2 (Simple) | ~10 minutes

Possibly related PRs

microlinkhq/metascraper#866: Introduces the rule-level validation extended by this change.
microlinkhq/metascraper#867: Introduces the scrape-level validation callback extended by this change.

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly and concisely describes the main change: passing propName to validate through the helpers package.

✨ Finishing Touches

📝 Generate docstrings

Create stacked PR
Commit on current branch

🧪 Generate unit tests (beta)

Create PR with unit tests
Commit unit tests in branch feat/validate-prop-name

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

_{Comment @coderabbitai help to get the list of available commands.}

Update index.js

b488d44

Kikobeats merged commit 8e0a75f into master Aug 9, 2026
26 of 30 checks passed

Kikobeats deleted the feat/validate-prop-name branch August 9, 2026 06:35

Navigation Menu

Repository navigation

feat(helpers): pass propName to validate - #868

feat(helpers): pass propName to validate#868
Kikobeats merged 2 commits into
masterfrom
feat/validate-prop-name

Kikobeats commented Aug 9, 2026 •

edited by coderabbitai Bot

Loading

Uh oh!

coderabbitai Bot commented Aug 9, 2026 •

edited

Loading

Walkthrough

Changes

Uh oh!

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Conversation

Kikobeats commented Aug 9, 2026 • edited by coderabbitai Bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Why

What

Test plan

Summary by CodeRabbit

Uh oh!

coderabbitai Bot commented Aug 9, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Walkthrough

Changes

Uh oh!

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Kikobeats commented Aug 9, 2026 •

edited by coderabbitai Bot

Loading

coderabbitai Bot commented Aug 9, 2026 •

edited

Loading