feat: enable Ajv2019 and Ajv2020

[jmjf]

Closes #151 and probably makes #105 moot.

The for...of approach to tests seemed simple. If maintainers don't like it, I'm open to input on what you'd prefer.

• run npm run test and npm run benchmark (there is no benchmark script)
• tests and/or benchmarks are included
• documentation is changed or added
• commit message and code follows the Developer's Certification of Origin
  and the Code of conduct

Checklist

• run npm run test and npm run benchmark
• tests and/or benchmarks are included
• documentation is changed or added
• commit message and code follows the Developer's Certification of Origin
  and the Code of conduct

[climba03003]

It doesn't look like same as before. Previously, accessing the .default.

Suggested change

	const Ajv = require(ajvPath)
	const Ajv = require(ajvPath)

[jmjf]

This allows using Ajv2019 and Ajv2020 by passing 2019 or 2020 in options.mode.

If options.mode is not one of JTD, 2019, or 2020, ajvPath is "ajv" (the default).

If I'm misunderstanding the question, please help me understand.

[climba03003]

I means const Ajv = require('ajv').default, now becomes const Ajv = require('ajv')
Unsure why the .default exist.

[jmjf]

I see. Thanks for explaining. This became a learning opportunity for me.

What I learned is, Ajv is ESM. According to Node docs

When an ES Module contains both named exports and a default export, the result returned by require() is the module namespace object, which places the default export in the .default property, similar to the results returned by import(). To customize what should be returned by require(esm) directly, the ES Module can export the desired value using the string name "module.exports".

In Ajv code, Ajv uses module.exports, so require('ajv') should get the Ajv class, which is the default export. The JTD, 2019, and 2020 versions do the same.

My guess is that, in the past, require().default may have been required to get the default export out of the module namespace object. The JTD code wasn't using .default and worked and this code works without .default.

I don't mind adding a commit to add the .default if wanted.

This morning, I woke up thinking I should typeof options.mode === 'string' to the ternary condition to avoid trying to call toLowerCase on a non-string (would default to plain Ajv if options.mode is not a string or is not one of the three recognized options).

But Array.prototype.includes doesn't coerce types, so non-string won't match and won't attempt to call toLowerCase, so not needed. (Another thing I learned.)

[jmjf]

Lint is failing in CI. When I ran lint locally on main, it failed with the same error. I'm not sure what the lint issue is.

[mcollina]

lgtm

[metcoder95]

lint seems failing

[Eomm]

I would refactor a bit here, because it is strange to me that we don't support the default version.

I would implement something like:

const supportedModes = new Map()

supportedModes.add('2020', () => require('ajv/dist/2020'))
supportedModes.add('2019', () => require('ajv/dist/2019'))
supportedModes.add('draft-04', () => require('ajv/dist/refs/json-schema-draft-06.json'))

[jmjf]

lint seems failing

Lint fails in main (see also this comment) with the same errors. At the time I created this PR, I saw several merged PRs that had the same lint failures.

If the team wants to recommend lint config changes the team considers acceptable, I'm willing to make them. (I use biome, not eslint, so am not familiar with eslint config.)

> @fastify/ajv-compiler@4.0.2 lint
> eslint


/home/jmjf/dev/ajv-compiler/types/index.d.ts
  12:18  error  'buildCompilerFromPool' is defined but only used as a type    @typescript-eslint/no-unused-vars
  15:18  error  'buildSerializerFromPool' is defined but only used as a type  @typescript-eslint/no-unused-vars

✖ 2 problems (2 errors, 0 warnings)