Feature Request: Add `unregisterAllSchemas()` to clean up registered schemas in test suites

[Suyog241005]

Context

While contributing to and working with the repository, I noticed that all the test files (lib/schema.spec.ts) have to manually track and unregister every single registered schema inside their afterEach hooks:

afterEach(() => {
  unregisterSchema(`${testDomain}/schema`);
  unregisterSchema(`${testDomain}/relative-schema`);
  unregisterSchema(`https://example.com/schema`);
});

The Problem

Currently, there is no public API to clear or flush the entire schema registry at once.

If any one forgets to unregister even a single schema in a spec file, that schema leaks into all subsequent tests. This results in state pollution, making it difficult to guarantee test isolation and potentially causing unpredictable test failures depending on the execution order.

Proposed Solution

Exposing a simple, top-level unregisterAllSchemas() function would solve this perfectly. It would allow developers to completely reset the registry's state.

We can define it by leveraging the existing getAllRegisteredSchemaUris() and unregisterSchema(uri) methods:

export const unregisterAllSchemas = () => {
  for (const uri of getAllRegisteredSchemaUris()) {
    unregisterSchema(uri);
  }
};

This would:

1. Provide a standard, robust way to reset the registry.
2. Drastically simplify the repository's own unit tests by replacing repetitive unregisterSchema lists with a single unregisterAllSchemas() call.

Please let me know if this looks like a valid addition! I would be very happy to implement this and open a PR to clean up the test suite.

[Suyog241005]

Hi @jdesrosiers ,
Just to follow up on this, I went ahead and drafted a working prototype of unregisterAllSchemas() locally, and refactored our internal test suites to utilize it in the afterEach hooks.
Please let me know if you would like me to open the PR for your review!

[jdesrosiers]

Unfortunately, it isn't that simple. We can't simply remove all registered schemas because that would also remove things like meta-schemas that need to always be there. There's no reliable way to distinguish between a schema that needs to always be there and one that was registered by the user.

[Suyog241005]

Hi @jdesrosiers,

That is an excellent point! I completely see what you mean now. Wiping the registry indiscriminately would remove the core meta-schemas (and any custom dialects) that are loaded at module startup, causing subsequent compilations to fail.

To solve this elegantly without having to guess which schemas are "system" schemas vs "user" schemas, what if we introduced a Checkpoint/Snapshot API instead?

We could expose two lightweight, safe functions:

• recordSchemaRegistryCheckpoint(): Captures a list of all currently registered schema URIs (e.g., in a simple array).
• restoreSchemaRegistryCheckpoint(checkpoint): Wipes only the schemas that were added after the checkpoint was taken, by comparing the current registry against the checkpoint.

This keeps the core meta-schemas safe, handles custom dialects perfectly, and gives developers full control over test isolation.

Example Test Suite Usage:

let registryCheckpoint;

before(() => {
  // Capture the baseline state after all imports/dialects are initialized
  registryCheckpoint = recordSchemaRegistryCheckpoint();
});

afterEach(() => {
  // Safely roll back only the schemas registered during individual tests
  restoreSchemaRegistryCheckpoint(registryCheckpoint);
});

[jdesrosiers]

I was thinking about something a little different for v2, but we might be able to do something similar without breaking backward compatibility.

We could refactor to support multiple registries, then allow users to add and remove registries as needed. The system registry that contains meta-schemas would be the only one that can't be removed.

Something like this,

const registry = new SchemaRegistry();
registry.registerSchema(schema, schemaUri);

useRegistry(registry, "label");

const result = validate(schemaUri, instance, BASIC);

removeRegistry("label");

[Suyog241005]

Hi @jdesrosiers,

That makes total sense — a proper multi-registry architecture is definitely the right long-term solution, and worth doing properly in v2 rather than patching it in v1.

Looking forward to seeing that design take shape! Is there anything I can help with in the meantime — whether it's related to this issue or elsewhere in the codebase?