Bug: Build crash due to unsafe object property access in remark plugins

[h30s]

Description

While working with the local build pipeline, I discovered a bug in the custom remark plugins that can cause the entire build process to crash with an unhandled TypeError.

The issue stems from how heading IDs are tracked in remark/remark-headings.js. Currently, they are stored in a standard JavaScript object:

file.data.headings = {};

Later, in remark/remark-reference-links.js, the code checks for the existence of an ID using the in operator:

if (!(id in file.data.headings)) {
  throw Error(`ReferenceLinkError: No header found with id "${id}"`);
}

Because file.data.headings is a plain object, it implicitly inherits properties from Object.prototype (like constructor, toString, or __proto__). If a document contains a heading or a reference that normalizes to one of these built-in property names (for example, a heading titled "Constructor"), the in check erroneously returns true.

Instead of throwing the intended ReferenceLinkError, the plugin attempts to treat the native function (e.g., Object.prototype.constructor) as an AST node, leading to a fatal crash downstream:
TypeError: Cannot read properties of undefined (reading 'section')

Why this matters

This is a critical Developer Experience (DX) issue. In technical specifications, terms like "Constructor" or "Prototype" are extremely common as headings. If an author refers to one of these via a reference link (e.g., {{constructor}}), the CI build will fail with an obscure error message that provides no hint to the author about what went wrong in their markdown.

Steps to Reproduce

1. Create a markdown file with a heading named constructor:

   # constructor
   Reference: {{constructor}}

2. Run the build command: npm run build
3. The build will crash with TypeError: Cannot read properties of undefined (reading 'section').

[NandiniDhanrale]

Opened PR #1675 to fix this by using a safe headings map (Object.create(null) + own-property checks) and adding a regression test for the constructor case: #1675

[h30s]

@NandiniDhanrale I had also implemented a similar solution locally (using Object.create(null) to prevent prototype collisions) and was waiting for maintainer feedback on this Issue before opening a PR.

[NandiniDhanrale]

Thanks for mentioning that! I’ve opened a PR with an Object.create(null) + own-property check and a regression test for the constructor case, so maintainers can compare approaches. Happy to adjust the implementation if reviewers prefer a different pattern.

[jdesrosiers]

I was able to reproduce the bug, but it's a little different than described. The correct way to define the heading is,

# Constructor {#constructor}
Reference: {{constructor}}

This breaks in a different way, but produces a warning.

The TypeError comes from trying to reference a heading id that doesn't exist.

Reference: {{constructor}}

Anyway, the proposed solution should work.

@NandiniDhanrale I'm closing your PR because it was very rude of you to create a PR for an issue that someone else created and intend to provide a fix for. In the future wait to be assigned an issue before submitting a PR.

@h30s Please submit your PR.