fix: assign schemas to host ajv instance

[diogosilva95]

Fixes the issue #113 by adding the schemas to the internal avj instance used by the plugin

Checklist

• run npm run test and npm run benchmark
• commit message and code follows the Developer's Certification of Origin
  and the Code of conduct

[Fdawgs]

@diogosilva95 The CI is failing, can you add a unit test as well please?

[diogosilva95]

@Fdawgs added the test and fixed lint :)

[climba03003]

Not sure if it is a good idea, when encapsulation is exist, you can have same $id with different content.

[diogosilva95]

Note sure if it is a good idea, when encapsulation is exist, you can have same $id with different content.

would you provide an example please? when you add a schema to the ajv instance with an existing id it throws an error

[climba03003]

when you add a schema to the ajv instance with an existing id it throws an error

That is the exact problem I mention, fastify allows the same $id of schema exists across different encapsulated context.
You can see the below foo schema shared the same name but different properties.

import fastify from "fastify";

const app = fastify();
app.register(async (instance) => {
  instance.addSchema({
    $id: 'foo',
    type: 'object',
    properties: {
      foo: { type: 'string' }
    }
  })
})
app.register(async (instance) => {
  instance.addSchema({
    $id: 'foo',
    type: 'object',
    properties: {
      foo: { type: 'string' },
      bar: { type: 'string' }
    }
  })
})
await app.ready()

[mcollina]

Isn't addSchema encapsulation aware?

[Eomm]

LGTM

The ajv instance is encapsulated too.
I would just add another test to cover the cliba feedback 👍🏼

[climba03003]

The ajv instance is encapsulated too.

The problem is similar to @fastify/swagger. The instance of ajv is global in the root context of registered level.
So, the problem still persist, unless it creates a new instance of ajv on each new context creation.