@std/yaml: expose/enable custom tag (!Foo / !!foo) support (I can implement)

[hnordt]

Today @std/yaml parses tag properties, but end users cannot register custom tags. Any unknown explicit tag (for example !User, !Entity, !!my/tag) fails during resolution.

This blocks some YAML patterns used in some DSLs and configuration systems.

What I'm trying to do

Parse YAML like:

- !Entity
  name: Workspace

- !Entity
  name: User

And have !Entity resolved into a custom runtime structure (or at least a predictable representation), instead of throwing an unknown tag error.

Current limitation

• parse() only accepts a schema name ("failsafe" | "json" | "core" | "default" | "extended").
• There is internal schema/type machinery (type maps and tag resolution).
• However, there is no public API to register custom explicit or implicit tag handlers.
• parse() explicitly states that parsing untrusted data is safe. Any custom tag mechanism would need to keep this guarantee explicit and opt-in.

Question

Are you open to adding custom tag support to @std/yaml?

If yes, I would like to implement it.

My goals would be:

1. No breaking changes.
2. Default behavior remains unchanged.
3. Custom tags are fully opt-in.
4. The "safe for untrusted input" guarantee remains explicit and documented.
5. The design fits the current internal schema + type map architecture.

Possible API Directions

Option A: Allow passing explicit/implicit types via parse options

parse(yamlText, {
  schema: "default",
  types: {
    explicit: [
      {
        tag: "!Entity",
        kind: "mapping",
        resolve: (data) => true,
        construct: (data) => new Entity(data),
      },
    ],
  },
});

Option B: Expose a public createSchema() or extend getSchema()

Allow users to build a schema with custom explicit + implicit types, and pass it to parse().

This would align with the existing internal schema design.

Option C: Minimal tag resolver map

parse(yamlText, {
  tagResolvers: {
    "!Entity": (data) => new Entity(data),
  },
});

This would be a simpler abstraction layer over the internal type system.

I can implement

If maintainers confirm that custom tag support is something you are open to, I can:

• Propose a concrete design
• Implement the feature
• Add documentation
• Add tests
• Ensure full backward compatibility

Thank you.